同意。 pip 依赖链接的当前行为真的很糟糕。

4295

3610

[写在#3939，把我的评论移到这里]

所以，这里的主要问题：如果我不希望使用requirements.txt文件（因为，说，我想在所有指定的声明依赖性setup.cfg ），我怎么指定URL 作为依赖项？

这不起作用：

[options]
install_requires = 
  requests==2.18.4
  https://github.com/example/example_lib/archive/master.zip

我也认为相关性的联系是怪异和精细下降，但如果规范地不与如何提供这种使用情况？

另一个问题是dependency_links显然不能在 setup.cfg 中指定，只能作为 setup.py 参数。 如果它们不被推荐，那应该被修复。

有没有这方面的消息？ 是否有任何替代方案？ dependency_links_ 似乎是库的内部/私有分发的唯一选择。

而不是弃用它，它应该被修复，很多人忘记或感到困惑，因为他们忘记将库的名称版本放在 install_requires 和包含 tarbal 和鸡蛋的依赖项链接中。 作为替代方案，我很想看到@jleclanche建议，一个指向 install_requires 中 tarball 的简单链接（指定鸡蛋可能是可选的）。

我认为我们并不孤单： https :

多年来，像 devpi 这样的

@dstufft顺便说一句 - 我想争辩说，devpi 的存在展示了一个更干净的解决方案，使依赖链接变得不必要的问题

恕我直言，索引继承+白名单/黑名单在操作层面上更加一致和易于理解

@RonnyPfannschmidt ，感谢您的建议，似乎我遗漏了一些重要的东西（关于这种弃用的讨论已经持续太久了），但总的来说，我不能更同意来自reddit 的评论：

devpi 可能是一个解决方案，但是将另一项需要维护并必须等待管理员设置的服务引入到游戏中，不会让我很快开始工作。 此外，我们仍然需要构建包，然后将它们放到 devip 上（或者 devpi 具有跟踪 git 存储库的功能？？）

理想情况下，我想要一个替代方案，它不会只需要在我的库中添加一个文件，或者在 setup.py 中添加几行。

我基本上不明白删除它的基本决定，我可以看到它如何导致不良做法和不安全感，但只要保留供内部使用，它应该不是主要问题。

4175 意味着 PEP 508 URL 支持将出现在 pip 10 中。我认为这可以关闭。

想法@pfmoore @dstufft？

我认为https://github.com/pypa/pip/pull/4175/commits/86b07792e7ae762beeaeb471ab9db87e31bc285d意味着@语法不能用于依赖项，所以这意味着 #4175 不是这个问题的解决方案. 那里的评论是，在 PyPI 能够阻止使用它的上传之前，我们不应该实现对依赖项的@支持（因为我们不希望从 PyPI 安装某些东西以便能够从任意 URL 获取内容，大概）。

除非有替代方案，即 PEP 508 支持，否则不应弃用它。 在那之前，太多人在使用它。

什么是正确的工作流程？

假设有一个我需要添加功能的库。 我在 Github 上分叉了它。 特性不会很快被合并，所以我有一个工具，我设置为使用我的 Github fork 而不是 PyPi。

现在我的所有用户在使用 pip 安装我的工具时都必须添加 --process-dependency-links，这是一个已弃用甚至曾经删除的标志？

setup.py 中是否有我遗漏的选项，或者真的没有办法解决这个问题？ 似乎唯一可行的方法是推出一个分叉的 pypi 包。 无论如何，一旦您的拉取请求合并，这只会增加用户的困惑。

让我们来谈谈这个。

--process-dependency-links今天真的没有其他选择。 因此，我建议我们继续并取消弃用它。

但是，该标志确实意味着 pip 会访问任意 URL——它应该附有关于此的警告。

@pradyunsg除非有一个真正的计划将其

我不认为真正需要它的人有任何动力去解决这个问题，除非 pip 说“不，我不承担你的债务”

作为 pip 维护者，我担心的是不允许 pip 成为漏洞利用的载体。 Pip 假定 PyPI 作为默认索引，因此对 PyPI 存在隐式信任。 所以我的第一个问题是：

1. PyPI 上是否存在具有dependency_links元数据的包？
2. 是否可以修改 PyPI 以拒绝使用dependency_links上传项目（或者它已经这样做了）？
3. 或者，pip 是否可以简单地拒绝处理从 PyPI 下载的包的依赖链接（无论是否设置了该选项）？

如果我们能确定 pip 用户没有办法被 PyPI 上带有恶意dependency_links的包所咬，我就不会那么担心了。 选择使用自定义索引的用户必须自己决定是否信任它。 （即便如此，我仍然更愿意保留该标志——这可能是一个远程漏洞利用，应该始终明确选择加入）。

因此，通过以下更改：

1. Pip 永远不会处理来自 PyPI 的依赖链接（明确的，或者只是因为我们知道它们不存在）
2. --process-dependency-links标志未弃用，但仅适用于自定义索引。

我愿意接受它作为现状。 需要依赖链接样式功能的人们可以在他们之间讨论他们想要如何（如果有的话）继续前进。

如果有人愿意，我们可以将所有这些都放在定义依赖关系链接元数据的标准中，然后当前的弃用将变为“将放弃当前行为以支持标准中指定的行为”。 但是从以 pip 为中心的角度来看，我宁愿这样做 - 让需要依赖链接的人承担标准化工作（毕竟这对他们有利，因为他们有一条路线 - 获得标准更改- 以完全社区共识修改 pip 的行为）。

基本上我们有一个功能是为了替换依赖链接，但是 pip 还没有开始尊重它，因为我们还没有办法阻止上传到使用它的 PyPI。

你是说#4175？ 哪个因为 86b0779 被屏蔽了？ 也许我们可以修改https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L167仅在comes_from是 PyPI 时才给出错误？

然后我们可以更改--process-dependency-links的弃用警告，说用户应该切换到@语法，并在合理的弃用期后删除--process-dependency-links （我们必须开始从@语法可用的点开始计时）。

@pfmoore是的，就是这样，这似乎是一条可能的前进道路。

行。 如果没有其他人先得到它，我会考虑写一个 PR。

从我收集的信息来看，这里的用户问题是，当您将它传递给没有替代方案的功能时，他们需要传递一个明确表示“嘿，我已弃用”的选项。

我赞成在弃用期内完全放弃对dependency_links 的支持。 同时，添加 PEP 508 URL 依赖支持，我确实认为 pip 在使用时应该仍然很响亮，并且它们仍然应该选择加入。

那将意味着：

• 将处理 PEP 508 url-deps 的能力放在一个标志后面
  
  
  
  • 旁白：应该命名标志，以便关注安全的用户检查文档
  
  
• 开始拒绝安装来自 PyPI 包的 PEP 508 url-deps
• 依赖链接仍然被弃用，但我们有一个日期我们会放弃它们
  
  
  
  • 老实说，与打印替代方案的单个版本相比，我不想给它更多的弃用期。
  
  

我昨天打了，但没有发送。 我现在意识到它与@pfmoore的最后一条评论基本相同。

_耶！

URL deps 是否需要选择加入标志？ PEP 508 没有这样说，当前的实现也没有那样做。 我可以看到逻辑，但我不相信我对安全性与易用性问题的判断。

另外，在我们开始推动切换之前，我希望看到一些关于项目应该如何从依赖链接切换到 @ 语法的清晰文档。 已经很难接触到将受到弃用影响的人，并且警告他们无法解决如何解决的问题也无济于事。 理想情况下，警告应包含指向“如何转换”文档 IMO 的指针。

我不相信我对安全性与易用性问题的判断。

我倾向于：“默认情况下是安全的”并选择加入不太安全的行为。

在我们开始推动切换之前，关于项目应该如何从依赖链接切换到 @ 语法的清晰文档

听起来不错。

我倾向于：“默认情况下是安全的”并选择加入不太安全的行为。

作为在我的工作中难以处理防火墙和安全限制的人，我非常清楚我们对这种功能可能最有用的环境类型（内部开发、闭源，严格控制的工作流程和网络布局等）。 所以我的倾向是确保默认工作流程 (PyPI) 的安全，但不会在具有对他们的工作流程显然很重要的用例的人的方式上设置额外的障碍，但我们没有正确理解他们必须进行的权衡制作。

在我看来，“如果包来自您明确选择使用的服务器”就足以选择允许 URL 链接。

看？ 这并不是说我没有意见，只是我不知道我的偏见没有显示：微笑：

不要给具有明显对他们的工作流程很重要的用例的人设置额外的障碍，但我们没有正确理解他们必须做出的权衡。

很公平。 如果一些用户可以提供有关他们工作流程的见解，那就太好了。

“如果包来自您明确选择使用的服务器”就足以选择允许 URL 链接。

我不确定这里。 ：/

看？ 不是我没有意见，只是我不确定我的偏见没有表现出来😄

呵呵。

很公平。 如果一些用户可以提供有关他们工作流程的见解，那就太好了。

在我看来，“如果包来自您明确选择使用的服务器”就足以选择允许 URL 链接。

仅允许来自 GitHub 的资源就可以为我解决 99% 的问题。 上游包有错误或缺少功能。 我 fork 并修复它们，发布 PR，然后等待可能很长时间让它们合并，然后在 PyPI 上发布。 与此同时，我的软件包依赖于这些软件包中的修复程序。

只要可以在一行中完成，就可以选择加入。

使用直接链接（假设是 HTTPS/etc）并不是真正的安全问题，这只是一个可用性问题。 由于我们不允许 PyPI 使用它们，所以我会说这已经足够了，我们不需要另一个标志。

在我的工作中，我们会陷入@pfmoore提到的一些用例中，即在包开源、闭源等之前的内部开发（总是内部包依赖于其他内部包，所有这些都在版本控制服务器中）。
虽然，我也看到有人提到文件系统位置的可能用例......
提供列入白名单的主机/位置列表是否有意义？ 正如@pradyunsg建议的那样，IMO 的标志名称应具有足够的描述性，以使用户意识到所涉及的风险。 也许--whitelisted-host ？

@masdeseiscaracteres我想你可能误解了 - 我的意思是，如果从 PyPI 检索一个包，如果它的任何依赖项是通过@引用指定的，我们就会失败。 但是无论如何都不应该在 PyPI 上出现任何这样的情况（我们希望在某个时候拒绝它们，我们只是还没有能够设置它）。 @引用的所有其他用途都可以。

看起来我们将继续进行 PR，它执行@pfmoore在https://github.com/pypa/pip/issues/4187#issuecomment -389846189 中所描述的内容。

欢迎 PR。 :)

请注意，我没有时间解决这个问题 - 不是因为更改很困难（如前所述，它似乎只是对comes_from进行检查），而是因为我不知道如何激发自己出错（更重要的是，我不知道如何编写这样的测试）。 如果有人可以提供此类测试用例的示例，那将非常有帮助。

如果有人可以提供此类测试用例的示例，那将非常有帮助。

有一个现有的测试test_install_pep508_with_url_in_install_requires可以证明这一点。

至于从 PyPI 安装时出错，我认为没有比在 PyPI 上实际上传具有 URL 要求的内容更好的选择。 😞 为此，我在 PyPI 上上传了一个包。 https://pypi.org/project/pep-508-url-deps/

另一件事是 - comes_from不是 URL 或路径，它是沿着'box==0.1.0 from file:///private/tmp/box'行的字符串。 无论谁想要解决这个问题，现在都必须想出更好的方法来排除错误，以便我们获得有关包来源的信息。 :)

@pfmoore这个问题在我心目中很近而且很重要😄@ pradyunsg的上传是否给了你你需要的东西，你还打算解决这个问题吗？ 如果没有，我可以尝试一下。

@bstrdsmkr不，正如@pradyunsg所说，这并不像我想象的那么简单，因为comes_from不是源 URL。 所以我不知道我现在什么时候有时间（我没有个人使用这个功能，所以它在我的优先级列表中并不高）。

如上所述，欢迎 PR :-)

我要补充一点，上传的包对实现没有任何帮助，它只对测试功能有帮助。

我的理解是，所需的修复类似于：

if req.url and is_like(req.url, PYPI.url):
    raise

在https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L172
如果 url 位于同一域，则is_like()返回True 。 那是对的吗？

是的。 我认同。 那将是代码更改。

而且，我们需要添加/更新测试和新闻条目。

我还认为，此更改非常重要，足以保证弃用消息有机会提供指向文档的链接 + 用户指南中的附加部分，告诉人们如何切换到替代方案。

作为 pip 维护者，我担心的是不允许 pip 成为漏洞利用的载体。 Pip 假定 PyPI 作为默认索引，因此对 PyPI 存在隐式信任。

不，有明确的信任。 并且增加保护措施以防止在依赖项中使用外部源恕我直言不会改善这种情况：在 pypi 中隐藏恶意软件比在公开可用的 VCS 中更方便。

恕我直言，更好的方法是使用开发人员的 VCS 作为主要来源，并将 pypy 作为指向它们的注册表和缓存代理，并具有一些强大的加密证明，以证明 VCS 中的内容与从 pypy 获得的内容相同。 我是说

0 注册

dev -- public key --> pypa

1 上传

setuptools -- git+https:/.... --> pypa
pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks the signature matches the dev

2 空闲：

pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks it

2 检索

flips a coin
if coin == 1:
  pip -- give me package git+https:/... --> pypi
  pip <-- signature || content -- pypi
  pip -- give me the signature --> vcs
  pip <-- signature -- vcs
else:
  pip -- give signature of package git+https:/... --> pypi
  pip <- signature -- pypi
  pip --> Tor --> give me that commit --> vcs
  pip <-- Tor <-- here -- vcs


pip checks if the signature matches the public key and signature from pypa
pip -- give me public key --> keyserver
pip <-- PK -- keyserver
pip checks signature given by VCS against the sdist given by pypy
pip caches public key and repo location

1 由于签名，安装的源与 VCS 中的源匹配
2 作者太配
3 pypa可以对新用户作弊，但作弊可能被老用户发现
4 作者可以通过在 web interface 分支中显示而不是给 pypy 并发送到 pypy 另一个分支来作弊。 如果我们使分支成为 URI 的必需部分，它将无法正常工作。

@KOLANICH当你说 pypy/pypa 时，我认为你的意思是 PyPI（Python 包装索引）。 PyPy 是 Python 的另一种实现。 PyPA（Python Packaging Authority）是一群志愿者，他们维护 Python Packaging 领域的主要项目。 请务必正确使用首字母缩略词或避免使用它们。

您建议从根本上改变现有完善服务的设计。 如果您希望进行此类重大更改，欢迎您提供至少一个（可行的）过渡计划和 POC 实现，用于管理/更改架构以允许过渡/最小化现有工作流的破坏。 请注意，依赖外部托管是过去在PEP 470 中从 PyPI 中明确删除的内容，但这与您所建议的情况完全不同。

PyPI 由志愿者维护，在捐赠/赞助的基础设施上运行。 你建议它通过 Tor 连接，Tor 是另一个志愿者维护/运行的服务。 这两个都是重大项目，即使它们不是由用户直接承担/可见的，也有与保持它们运行相关的成本。

尽管如此，这不是本次讨论的合适地点。 如果您确实希望提议重新设计 PyPI，我建议您在https://github.com/pypa/warehouse重新开始讨论

感谢您的建议。

请参阅 #5571 -- 对此的 PR，了解为什么将其推送到更高版本。

PIP 安装日志中的警告给出了这个 URL，但是这里和提到的其他票证都没有解决问题的方法。

而且，这更令人困惑：你说PyPI是什么意思？ 你的意思是任何实现 PyPI 接口的服务器（例如 Artifactory），或者，特别是 pypi.org？

现在，显然，想要通过setuptools （又名运行setup.py install ）和使用pip install来安装软件包的人现在将陷入困境。 在这种情况下，指定依赖链接是处理多个相互依赖的包的唯一方法。

现在，如果我错了，请纠正我，但到目前为止，如果您根据 PyPA 就上传到他们的服务器所做的任何决定将其取消，您基本上会使pip对 Artifactory 用户毫无用处/拥有包含相互依赖包的私有存储库的公司。

请告诉我，我错了，在整个故事中遗漏了一些东西（我断断续续地跟踪了一段时间）。 我红色 PEP 508，但在这方面确实没有区别，至少，我看不出它会如何使事情变得更好或更糟。

@wvxvw-traiana 我想你错过了 PR #5571
在该 PR 之前（以及当前版本 - 18.0），pip 将拒绝安装通过 PEP508 语法指定的任何依赖项。

在那个 PR（已经合并，所以应该在 18.1+ 中）之后，如果依赖于它们的包来自 pypi.org，pip 只会拒绝这样的依赖。

如果你从你的私人仓库安装一个依赖于 pypi 东西的包，显然这很好。
如果你从 pypi.org 安装一个依赖于你的私有仓库的东西的包，那会失败。
如果你从你的私有仓库安装一个依赖于你私有仓库中的东西的包，那很好。

希望能帮助解决问题

@bstrdsmkr是同源还是 pypi 是特例？ IE

如果你从你的私人仓库安装一个包，这取决于来自不同私人仓库的东西。

添加一些关于这背后的原因的进一步背景：

1. 直接 URL 链接允许包触发从 Internet 上的任何位置下载和运行任意代码。 如果您负责执行此操作的程序包，那没关系，因此我们允许基于该理解的直接 URL 链接。
2. 人们希望从 PyPI（特别是 PyPI，而不是一般的包索引）安装并信任他们从那里下载的包。 为了防止安装包的PyPI的暴露了大量的Python用户的一种妥协，我们不允许一封来自PyPI来包依赖于直接的URL链接（因为它规定对使用者的负担过于坚持自己要审计的一切来自他们用于链接到外部代码的 PyPI）。
3. 依赖链接是 setuptools 特有的机制，由 setuptools 的内部机制处理，而不是 pip。 因此，不同于直接的URL链接，我们没有对他们做什么任何控制。 这就是为什么我们弃用它们而支持标准的直接 URL 形式，我们自己处理。

想要支持通过 setuptools（又名运行 setup.py install）和使用 pip install 安装软件包的人现在将处于泡菜中。

如果为真，那是因为 setuptools 没有实现对直接 URL 链接的支持，这是一个公认的标准。 随意向他们提出这个问题。

如果你从你的私人仓库安装一个包，这取决于来自不同私人仓库的东西。

这很好用。 不涉及 PyPI。

好的，所以，一方面，我很高兴这不会影响我。

另一方面，这个“修复”似乎，我怎么说……太容易解决了。

echo "not-pypi 151.101.61.63" >> /etc/hosts
pip install --index-url not-pypi

真的不是我的事，但似乎是一种真正的表面方法。 （在其他评论中提到了其他攻击媒介，您可以在 setup.py 中简单地下载任何您想要的内容）。

它的设计并不是为了让用户很难被用户解决。 这是一种为 PyPI 还没有办法阻止人们上传具有直接 URL 依赖项的包的事实提供（有限的）解决方案的方法。 有关某些上下文，请参阅https://github.com/pypa/pip/pull/4175#issuecomment -266305694。

@dpwrussell pypi.org 是一个特例。 更改后，任何私人回购到任何私人回购都可以正常工作。

@wvxvw-traiana 并不是要阻止您自己这样做。 当您认为您只是从 pypi.org 安装软件包时，它旨在防止其他人对您这样做

与当前的讨论无关，我将重新打开它，因为我们实际上还没有为此更新弃用警告。

5726 添加了建议使用 PEP 508 URL 的语言，IMO 是为此所需的最后一点。

那好吧。 让我总结一下：

• 依赖链接仍然被弃用，现在计划在 pip 19.0 中删除。
• 它的标准支持替换是 PEP 508 URL 依赖项
• 从 PyPI 安装时，如果包具有 PE​​P 508 URL 依赖项，将导致 pip 中止安装。

@pfmoore在此处详细说明了这些决定的原因： https :

@pradyunsg何时在 setup.py 的install_requires中允许 PEP 508 URL 依赖项？ 有日期吗？

在 pip 的下一个版本中——即 18.1，计划于 10 月发布。 您可以在 https://pip.pypa.io/en/latest/development/release-process/ 阅读有关 pip 3 个月发布周期的更多信息。 :)

https://github.com/pypa/wheel/issues/249需要在 PEP 508 URL 依赖成为可行的替代方案之前得到解决。

在 PEP 508 URL 依赖成为可行的替代方案之前，需要解决pypa/wheel#249 。

这已得到解决。

在 pip 18.1 发行说明中，它说

允许将 PEP 508 URL 要求用作依赖项。

作为一项安全措施，如果从 PyPI 安装软件包时，pip 将引发异常，如果这些软件包依赖于未托管在 PyPI 上的软件包。 将来，PyPI 将直接阻止上传具有此类外部 URL 依赖项的包。 (#4187)

所以这基本上意味着可以使用 URL 指定依赖项，但是如果这些不是 PyPI URL，则无法使用 pip 安装包？ 也许我完全弄错了，但是应该如何使用 URL 依赖项呢？

托管在 PyPI 上的@JarnoRFB包不能具有 url 依赖项。

不在 PyPI 上托管的包可能具有 url 依赖项。 如果您直接从 github 安装包（例如），将解析并安装 url 依赖项。 此类安装的示例：

pip install git+https://github.com/bstrdsmkr/some_package.git

本质上，如果您从 url 安装，它可以依赖于 url，否则就不能。 并且为了清楚起见，它还可以同时具有 url 和非 url 依赖项

一个小补充：

...如果你从一个 url 安装，它可以依赖于 url

...如果您从 URL（VCS 或其他）或本地文件或非 PyPI 的包索引安装，它可以...

那么是否有按照上述描述处理 install_requires 的 pip 版本？ 我无法计算出最终状态之上的标签，当前的 pip 文档指向 setuptools 中的install_requires文档，该文档仍然说使用dependency_links 。

我自己无法与文档交谈，但是这种允许非 PyPI 包从 url 安装依赖项的“放松”是在 pip 18.0 中发布的

AFAIK，从 pip 18.1 开始支持 install_requires 中的 URL 依赖项：

允许将 PEP 508 URL 要求用作依赖项。

来源：发行说明

呃，我的错别字——

我想在这里留下一个小而成功的例子，给那些第一次遇到这个问题的人（像我一样）害怕如何处理 --process-dependency-links。 使用此工作流程，我的用户现在可以从 GitHub 或本地源（不是 PyPI）进行 pip install，或者 pip install requirements.txt，或者 python setup.py install，并使用 pip 在 Travis-CI 上工作版本 18+，所以我认为它涵盖了很多基础。 我希望它对某人有用，如果这对其他人来说似乎偏离主题，我深表歉意：

在您的 requirements.txt 文件中，假设您希望人们能够依赖包“foo”的 GitHub dev 分支，例如：

scipy>=0.17
matplotlib>=2.0
foo @ git+https://github.com/foo-organization/foo@dev#egg=foo-9999

在您的 setup.py 文件中：

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

有人会说将install_requires和requirements.txt混为一谈是不明智的，对于已发布的版本，我同意，但我认为这对开发很有效。

啊，整洁。 因此，如果说包“A”和“B”都使用这种方法，并且包“A”将“B”列为依赖项，那么当您安装“A”时，它实际上最终会处理“B”的requirements.txt （通常不会） - 是吗？

我今天早上还读到 install_requires 本身有点糟糕，因为这些安装是由 setuptools 完成的，这意味着任何 pip 选项都被忽略，但我不知道该信息是否已过时......

我今天早上还读到 install_requires 本身有点糟糕，因为这些安装是由 setuptools 完成的，这意味着任何 pip 选项都被忽略，但我不知道该信息是否已过时......

您将install_requires与setup_requires混淆

啊，整洁。 因此，如果说包“A”和“B”都使用这种方法，并且包“A”将“B”列为依赖项，那么当您安装“A”时，它实际上最终会处理“B”的requirements.txt （通常不会） - 是吗？

@stevebrasier是的，我认为会，如果您在 A 中固定了其他所需软件包的不同版本而不是在 B 中，这可能会出现问题。

大家好，我只是想指出，在这种情况下，弃用途径太短了。 我知道依赖链接被标记为已弃用已经有一段时间了，但是可用于替换它们的 PEP 508 URL 直到 18.1 才被实现。 因此，从依赖链接切换到 URL 需求的时间只有 3 个月，这对于大型项目来说是非常短的时间。

@rgerkin嗨，我正在尝试按照您的指示操作但无济于事，

正在搜索 PACKAGE@ git+ ssh://[email protected] :OWNER/PACKAGE。 git@BRANCH
阅读https://pypi.org/simple/PACKAGE/
找不到“PACKAGE”的索引页（可能拼写错误？）
扫描所有包的索引（这可能需要一段时间）
阅读https://pypi.org/simple/

包@ git+ ssh://[email protected] ：所有者/包。 git@BRANCH ，这是在 install_requires 中。

你知道为什么我得到上述信息吗？

@KevinMars我的示例与您所拥有的示例之间存在一些差异，包括使用 git_ssh、bitbucket、a.git 后缀、命名分支和无版本标记。 也许这些事情中的一项或多项导致 pip 在 PyPI 上而不是在您的 URL 上进行搜索。 你用的是什么版本的pip？

评论我发现的一些东西：使用setup.py安装带有python setup.py install仍然需要在dependency_links声明外部依赖项。

在您的 setup.py 文件中：

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

@rgerkin感谢分享这个解决方案。 但是如果我使用 pbr 来设置我的 Python 包呢？ 如何调整它以适应 pbr？

@KevinMars我有同样的问题。 你有没有想过解决办法？ 我正在尝试通过 SSH 要求私有 bitbucket 存储库的特定分支。

我刚刚意识到 --process-dependency-links 不再存在。 我感谢社区所做的所有工作。 试图在永无止境的讨论中证明决定的合理性，并选择解决问题的迷宫和重定向问题，但我仍然认为离开这个选项不会伤害任何人。