Fabric: 一旦 Paramiko 2.0.x 绝对稳定，请考虑碰撞 Paramiko 要求引脚

也许考虑一个中间状态，对于一两个版本， fabric setup.py允许paramiko>=2和paramiko<2 ，人们将获得cryptography默认情况下，但如果需要，可以强制使用旧的PyCrypto版本。 一旦它被烧掉一点，你可以移动setup.py到 require paramiko>=2 。

不确定我是否曾经让 Fabric 1.x 需要 paramiko>=2，计划将其保存为 Fabric 2.x。 我猜这取决于 Fabric 2.x 的使用情况。

你是对的，回到未固定的“我不在乎，paramiko 1 或 2 没问题”仍然可以通过让人们手动降级他们的 Paramiko 来解决。 钉住主要是为了阻止大量的“onoz 你破坏了我的构建”报告。 我们得到了一些，但不是一吨，这是否是由于我的别针造成的，这是任何人的猜测。

@bitprophet FWIW，我有一些数据！ 在过去的 2 周内（因此这包括 paramiko 2.0 实际发布前的几天），以下是 PyPI 中下载次数最多的 Paramiko 版本：

| 版本 | 下载 |
| --- | --- |
| 1.16.0 | 411903 |
| 2.0.0 | 308131 |
| 1.17.0 | 77360 |
| 1.15.2 | 47677 |
| 1.15.1 | 23893 |

对我来说，如此大量的 2.0 安装表明它可能是安全的，因此删除<2绑定是不必要的，对于大多数人来说它会工作得很好（或者很容易修复），并且对于那些可以不是在pip install fabric修复它之前简单地做一个pip install paramiko<2 。

至少有可能使用环境标记来告诉结构至少对 PyPy 使用 paramiko>2，目前的现状是该结构无论如何都不会安装？

@alex姗姗来迟，你的意思是“删除<2绑定是安全的”？ （而不是“不必要的”）：D

@Julian我假设您的意思是“根据当前解释器更改install_requires ”的另外几行？ 不反对即兴创作。 （虽然 IIRC 这样的黑客停止使用轮子，所以我们开始回避它们......？）

呃，是的，我的意思是它是安全的。

@bitprophet对于轮子你做同样的事情，只是在extras_require使用环境标记。

基本上你擦@dstufft的肚子，一个精灵就会弹出来。

（更严重的例子：https://github.com/Julian/jsonschema/blob/master/setup.py#L25 但你用python_version替换python_interpreter来调度它）。

我会试着把它放在 PR 中，这样你就可以看到它的样子，除非你打算让这一切发生？

哦，好吧，我只依稀记得不久前学习过那些东西。 显然后来忘记了。 如果这样做可以帮助某些人而不伤害大多数人，我绝对不赞成这样做。 公关将不胜感激。

回复：外部问题，我认为此时我在 Fabric 1.12+ 中将引脚撞到<3 （以及前面提到的其他加密货币清除，尽管它们必须成为条件，除非我想做paramiko>=2,<3 ，我不太赞成。当我戳这个并尝试确保同一个 Fabric 分支通过两个独立的 venv 测试时，我会看到事情变得多么丑陋，一个 w/Crypto 和 Paramiko 1，其他没有 Crypto 和 Paramiko 2)

嗨，大家好

本次讨论的小补充：
我们使用Macports来安装Fabric 端口，这取决于我们 macOS 工作站上的Paramiko 端口。
但最近 Macports 决定将Paramiko 从 1.16.0 版本升级到 2.0.1 ，当我们现在运行 Fabric 时，它不再起作用：

➜ fab deploy
Traceback (most recent call last):
  File "/opt/local/bin/fab", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2927, in <module>
    <strong i="13">@_call_aside</strong>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2913, in _call_aside
    f(*args, **kwargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2940, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 637, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 650, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 829, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'paramiko<2.0,>=1.10' distribution was not found and is required by Fabric

我通过使用 Macports 将 Paramiko降级到 1.16.0 版来解决这个问题，手动操作有点复杂，但最终让它再次工作。

我认为这是 Macports 的错误，他们应该等到 Fabric 兼容后再升级他们的树中的 Paramiko。

但无论如何，如果可以发布支持 Paramiko > 2.0 的新版 Fabric 那就太好了，这样我们就可以使用 Macports 和所有端口的最新版本再次使一切正常工作。

脾气暴躁，这很烦人 - 谢谢你的消息，@hostep。 （不想刻薄，但 - 也很惊讶 MacPorts 仍在使用中，我认识的每个人几年前都改用 Homebrew。很好的提醒，“最重要的”！=“镇上唯一的游戏”我猜:)）

昨晚我突发奇想地弹出了一个小小的 1.12（对自己的另一个好提醒：在讨论路线图时停止使用文字版本号 - 只需说“即将发布的功能发布”等）并且没有进行此更改，但仍然想要尽快做，所以可能是下一个小版本。

FWIW，我们（FreeBSD）遇到了同样的问题，不得不为 py-fabric 创建一个 paramiko1 端口和包。 也可以看看：

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213893
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214379

TLDR：<= 和 == 依赖是超级痛苦/烦人的，并且产生的问题比他们声称要解决的要多。

当上游只是主动测试其依赖项的最新版本（在开发中，在发布之前是执行此操作的最佳时间）并且不规定或约束依赖项版本控制时，下游用户和打包人员/搬运工的痛苦就会少得多，除非有些版本明确破坏了兼容性。

即使在这种情况下，限制也只是暂时的，并且仅当发布被破坏时才发布，并且仅当依赖项作者被通知时并且直到修复完成。

这种方法的好处是它告诉上游（和上游的上游）他们所做的决定实际上会影响他们的用户在实践中（不仅仅是理论上），并且有了这些知识，希望能够最大程度地减少将来再次发生的可能性。

要添加有关 Macports 问题的更多信息，它似乎已修复，因为他们在安装时添加了一个补丁，将 Paramiko 的要求从<2.0更改<3.0
我们现在在我们的 macOS 工作站上运行 Fabric v1.12.0 和 Paramiko v2.0.2，没有任何问题。

@hoste感谢您强调这一点

@hostep实际上，有时我在*_requires规范（从<= / ==到>=或'' ）端口，如果测试套件通过了更高版本的依赖项。 然而，这依赖于出色的测试，因此可能存在风险，尽管我们是 Fabric 的下游，但我们也不喜欢破坏我们的用户（下游）环境:)

更多数字更新...过去 6 个月概述：

和过去 2 周：

Paramiko 2.0.x 现在可以轻松占所有下载量的一半。 我想知道其他 50% 中有多少是由于这张票没有被合并:) 很快就会发现！

认为我会执行此操作并将其作为 Fab 1.13.0 弹出。

回顾了@Julian和我之前讨论过的内容，但只有在我想将更改限制为 PyPy 时才需要使用extras_require魔法； 在这一点上，我只是在做“允许 Paramiko <3”位批发......

有 PyPI

Gah，我当然忘记了兄弟票，#1462！ 1.13.1 在路上...编辑：和，合并/发布。

万岁！

2016 年 12 月 9 日 20:14，“Jeff Forcier”通知@github.com 写道：

Gah，我当然忘记了兄弟票，#1462
https://github.com/fabric/fabric/pull/1462 ！ 1.13.1在路上...

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/fabric/fabric/issues/1461#issuecomment-266111875或静音
线程
https://github.com/notifications/unsubscribe-auth/AAUIXlbJBlS0po_zKgQsUp7-y7I7WgbTks5rGbajgaJpZM4ITeNm
.