Fabric: 将不依赖于 ssh 的功能拆分为单独的库

创建于 2012-02-22  ·  55评论  ·  资料来源: fabric/fabric

事情即将来临，最好将 Fabric 的任务执行内容拆分到它自己的“第三方”工具/库中，这样它就可以独立于我们的 SSH 功能来使用/引用。

现在，任何想要使用 Fab-as-runner 的人都必须安装ssh和PyCrypto ，这很糟糕。

如果我们在任务运行和 SSH 之间进行拆分，将“Fabric”设置为“SSH + 对新运行器工具的依赖”比反之亦然更有意义（两者都是：向后兼容性和整体实用性）。

说到向后兼容，我将其标记为 2.0 是因为在 2.0 向后不兼容障碍下这样做更有意义（因为至少它为 Fabric 添加了新的安装依赖项），但是在 1.6 或如果时机更好，1.7也应该是很有可能的。

需要明确的是，这个新工具将：

  • 也许，可能，但可能不仅仅是我们在使用现有的工具，如 Paver

    • 摊铺机试图做的太多，我从来都不是它的 API 感觉的忠实粉丝

    • 真的不知道任何其他众所周知并且更适合用例的工具

    • 编辑：贝克实际上看起来不错，虽然它显然不是一个完美的匹配（什么都不会，任何事情都需要一些调整。）

  • 具有与 Fabric 不同的身份，同时可能保持“附属”

    • 名字头脑风暴来了。

  • 包含当前存在于 Fabric 中的“使用 args 从 CLI 将 Python 可调用文件作为任务运行”功能
  • 可能需要对该机器的工作方式进行一些重构，如果只是为了使后期集成更容易
  • 可能会立即实现一些剩余的大型任务运行器“缺少的功能”（真的只是 #452）
Packaging Refactoring Support
资料来源
picture bitprophet

最有用的评论

昨天发布了 Fabric 2.0 和 Invoke 1.0 as Python 3.5 的任何 ETA，并将成为 Ubuntu 16.04 LTS 的默认设置？

picture tebanep 于 2015-09-14
👍3

所有55条评论

：蛋糕：

kenreitz42 picture kenreitz42 于 2012-02-22

当然，一个完全适合用例的全新工具也始终是一种选择。

kenreitz42 picture kenreitz42 于 2012-02-22

更新了一堆描述。

@kennethreitz ：这真的有点像一个新的“东西”，只是基于 Fabric 的那一半的现有需求/功能集。 这个想法是让它成为自己的实体：安装、开发计划等，但仍由 Fabric 开发人员/社区控制。

bitprophet picture bitprophet 于 2012-02-22

想法：

  • 托尼 - 就像托尼大师又名监工（漫画书〜）
  • CEO - 运行事物，（或沙皇或类似的东西）

对不起，我很讨厌名字:(

dstufft picture dstufft 于 2012-02-22

还有诸如“柯克”之类的东西（如柯克船长）。

我试着想一些与运行任务有关的结构，但我想不出与任务+结构有关的东西。

但我不认为 Loom 也不是一个坏名字。

dstufft picture dstufft 于 2012-02-22

初始名称头脑风暴。

概念

  • 跑步/慢跑/等
  • 执行（订单，人，虽然这有点可怕，等等）
  • 任务（如待办事项、差事等）
  • 也许#461中的一些被拒绝或相似的名字，只要用织物编织或把东西放在一起的想法也适用于任务

PyPI 上未采用的名称

  • runner
  • executor
  • go

    • 与编程语言和/或棋盘游戏混淆，尤其是前者有一个专门称为go的二进制文件

    • 无论好坏，都有许多潜在的愚蠢任务名称，例如away或fuck_yourself或bother_somebody_else

  • weaver

二进制名称

感谢 OS X 词典应用程序提供的牛津美国作家词库！

  • run
  • execute
  • go

    • 往上看

  • create （如make ）
  • fabricate （太长，太容易与fab混淆）
  • fab （即这个新库的名称不同，但仍安装fab二进制文件；如果两者都存在于系统上，则 Fabric 优先？似乎是个愚蠢的主意。）
  • generate
  • produce
  • fashion （嗯）
  • build
  • devise
  • shape
  • setup
  • weave

今天不是顶级头脑风暴形式。 想要呻吟。

bitprophet picture bitprophet 于 2012-02-22

@dstufft Loom 是一个不错的名字，而 CEO 是一个基本不错的概念（不是漫画书参考的忠实粉丝，如果只是因为它看起来晦涩难懂，我从来没有听说过这个角色；））。 主要问题是想出一个好的二进制名称，我觉得一个动词几乎是它运作良好的必要条件。 不确定什么对其中任何一个有用。

bitprophet picture bitprophet 于 2012-02-22

老板：做事。

kenreitz42 picture kenreitz42 于 2012-02-22

参加。 有点像 Make，但适用于 Python。

kenreitz42 picture kenreitz42 于 2012-02-22

管理人员。

kenreitz42 picture kenreitz42 于 2012-02-22

我喜欢它以任务为导向的想法。 唔..

kenreitz42 picture kenreitz42 于 2012-02-22

@kennethreitz我喜欢 Boss，除了与某个新泽西本地人的潜在混淆（对不起，只是不是粉丝，大学室友体验不佳）

正如我对@dstufft 所说，二进制名称在这里绝对是关键，所以如果可以的话，请尽量记住这些。 如果项目名称作为二进制文件听起来有点愚蠢，那么一个伟大的项目名称将无济于事；）

bitprophet picture bitprophet 于 2012-02-22

女仆很有趣。 为您执行任务。 类似于“制作”。

巴特勒也是。 我们可以随机选择一个听起来像英国的管家名字。

kenreitz42 picture kenreitz42 于 2012-02-22

maid clean 、 maid release 、 maid test 。 我喜欢。

kenreitz42 picture kenreitz42 于 2012-02-22

除了影响我（无限的，自然的）男子气概之外， maid还不错，即使它不符合动词模式。 （即它是更好的非动词二进制名称之一。）（编辑：管家_do_做什么？Butle？）

bitprophet picture bitprophet 于 2012-02-22

我只是蹲下名字，以防万一。 到目前为止我非常喜欢它。

kenreitz42 picture kenreitz42 于 2012-02-22

Boss 作为库名称已被 FWIW

2012 年 2 月 21 日星期二晚上 8:38，Jeff Forcier 写道：

除了影响我（无限的，自然的）男子气概之外， maid还不错，即使它不符合动词模式。 （即它是更好的非动词二进制名称之一。）

直接回复此邮件或在 GitHub 上查看：
https://github.com/fabric/fabric/issues/565#issuecomment -4095609

dstufft picture dstufft 于 2012-02-22

intern也是一个非常棒的选择。

kenreitz42 picture kenreitz42 于 2012-02-22

@dstufft是的，我也想不出一个好的二进制名称， boss docs不太合适。

bitprophet picture bitprophet 于 2012-02-22

@kennethreitz在 IRC 上提到bake ，它确实适合 make/rake 主题，也适合作为调用动词（例如$ bake docs ，虽然在主题上它有点偏离，但感觉就像它' d更适合厨师或其他东西。

编辑：还有deliver 。 我对这个的最初反应是有些积极的（ $ deliver build $ deliver docs ）但是没有_great_项目名称与之配套，这不是有点太傻，而且有点长。

bitprophet picture bitprophet 于 2012-02-22

$ invoke taskname （项目名称： invoker 、 invoked 、???）

bitprophet picture bitprophet 于 2012-02-22

被调用。

kenreitz42 picture kenreitz42 于 2012-02-22

我真的很喜欢 Invoked 和invoke docs invoke tests invoke publish等。

dstufft picture dstufft 于 2012-02-22

项目名称也可以只是“调用”，二进制文件和项目是否需要不同的名称？

dstufft picture dstufft 于 2012-02-22

我认为“invoked”比“invoke”更有魅力，但两者都可以。

kenreitz42 picture kenreitz42 于 2012-02-22

名称不必不同，不，只是多次更有意义。

走到火车上时我有一个想法（现在在说火车上：P去智能手机网络共享！）这是我们_可以_可能跳过所有这些并简单地移动整个fab + fabfile.py边这个“新”库的东西（并称之为fabricator ）。

换句话说，为独立库设置一个可调用库，为使用 SSH 的设置设置一个不同的库并不一定要发生，甚至可能是有害的。

优点：

  • 不需要新的二进制名称
  • 无论如何，拥有两个二进制名称会令人困惑
  • 如果新的库_没有_使用“fabfiles”，我们也会有两种不同的“任务文件”类型，再次混淆/额外代码/等等

缺点：

  • 由于名称相似，两个项目之间的潜在混淆
  • 新项目必须具有额外的可扩展性，以允许所有 Fabric-isms（例如几乎所有 CLI 标志等）继续按原样工作

    • 即pip install fabricator给我们fab ，它会有一些小的标志集

    • 然后如果你pip install fabric ，突然相同的fab必须展示所有额外的 Fabric CLI 标志，如果不是其他东西的话

    • OTOH 这不像允许“客户端”代码扩展 CLI 解析是一件坏事，它只是需要预先完成更多的工作。

bitprophet picture bitprophet 于 2012-02-22

您可以让命令行客户端变得可扩展。 看看nose如何允许从它的命令行工具中表达插件入口点

dcolish picture dcolish 于 2012-02-22

我认为无论采用哪种方式，额外的可扩展性都是一件好事。

我认为名称混淆将是一个问题。

这是个人的事情，但我更喜欢invoke test invoke docs的外观，而不是fab test 。

就不同的二进制文件而言，我只是确保核心二进制文件（调用）是可扩展的，以允许所有结构的事情发生，然后让 fab 调用与调用相同的入口点（即实际的 fab/invoke 二进制文件将只是main() （或其他）的超简约调用者。

我想如果你去 2.0 之前的调用 + 结构路线，既是 fabfiles 又是“Invokefiles”？ 将被支持，然后使用 2.0 仅调用文件？

所以本质上我是+1的，因为它把它分成不同的“任务运行器”和“远程/ssh 东西”，为 1.x 放入兼容的垫片，并为 2.x 弃用东西。 我认为这种拆分会使两个库都变得更好，任务运行器将支持一些非常好的可扩展性（并且可能是可以轻松依赖、运行等的外部任务）。 远程/ssh 的东西将受益于拥有更小的职责集，使其更加专注/

反正我的美分。

dstufft picture dstufft 于 2012-02-22

我应该澄清我不讨厌其他方式，我很高兴这个讨论正在发生:)

dstufft picture dstufft 于 2012-02-22

@dstufft 非常感谢您的想法，我几乎同意所有这些。 你说的二进制文件只是存根是对的，这就是 Fabric 现在的工作方式，我关心的只是行为和用户混淆。

@dcolish我并不是要暗示不可能进行 CLI 扩展，并且鼻子绝对是一个很好的现有技术来检查。

如果我们使用“invoke”，文件名可能是invocations(.py) ？ 有点愚蠢/主题公园的一面，但它在语法上很合适，而且invokefile.py对我来说有点尴尬。 或者可能走 Rake 公约路线并使用tasks(.py) 。

部分相关，我认为我们也绝对应该关注/关注模块/文件夹方面的进展。 由于它只是 Python，因此仍然支持，但就教程材料和文档而言，将invocations/__init__.py设为默认值可能是一件好事。

bitprophet picture bitprophet 于 2012-02-22

我喜欢tasks.py 。 invocations.py输入起来很奇怪。

kenreitz42 picture kenreitz42 于 2012-02-22

好吧，您不必经常输入它，是吗？ ;) 但是，是的， tasks/或tasks.py在全球范围内更明显。

bitprophet picture bitprophet 于 2012-02-22

任务文件.py

kenreitz42 picture kenreitz42 于 2012-02-22

你invoke任务（.py|/），无论如何，措辞都很好：）

dstufft picture dstufft 于 2012-02-22

是的，“这些是tasks你invoke ”设置从将关键字与它如何工作的英文描述联系起来的角度来看非常好。 很明显，没有多余的装饰，没有自负等。

@kennethreitz我从来没有真正 _been_ 将 XYZFile 作为命名约定的忠实粉丝，尤其是因为这些天它经常_not_ 单个文件，我认为没有必要在 Fab 1.x 之外继续约定 :)

bitprophet picture bitprophet 于 2012-02-22

我非常希望看到这种情况发生。 我一直将 Fabric 视为一种通用的 Pythonic 方式来存储项目的“任务”，无论它们是基于本地的还是基于远程的，更接近于 Rake/Make。 然而，在尝试向新人介绍时，有几个人对此观点感到困惑，并将其仅视为一种部署工具。

我会第二个模块/文件夹方面，以便更容易制作可以插入的通用任务。 新风格的任务肯定是朝着这个方向发展的好方法。

askedrelic picture askedrelic 于 2012-02-22

@askedrelic是的，不幸的是，将其二合一总是有点令人困惑。

无关：我召集@tswicegood加入这个话题，因为他和我几周前讨论了这个问题，我认为他可能想参与进来。像往常一样，我保留不同意的权利；）

bitprophet picture bitprophet 于 2012-02-22

我被召唤了？ :-)

我喜欢将tasks作为模块而不是fabfile的想法。 更有意义，更短。 一方面，我讨厌必须安装完整的 dep 堆栈才能在 Armstrong 中运行fab test ，因此可以采取任何措施来提取我的优势。

至于命名，如何从安装外部可执行文件转变为让人们将其添加到底部：

if __name__ == "__main__":
    <some_mod>.main()

然后，您只需使用 Python。 我对可执行文件没问题，只是不知道是否有必要。

FWIW，几周前我开始了一个项目，用于处理名为flunky的包创建。 坚持伴随的主题， footman或lacky都可用（后者与lackie冲突——一个 Ruby 项目）。 另一个是 Friday，如girl/man friday 。 它通过了 GitHub/PyPI/Homebrew 测试，因为没有任何名称。 实际上，现在我想这将是我的第一选择。

打赌，我想知道@niran提交 PR 更新 README 以包含明显但可怕的主题曲需要多长时间。

tswicegood picture tswicegood 于 2012-02-22

我认为拥有一个 on-your- $PATH “二进制文件”（尤其是考虑到它当前_不是_一个真正的二进制文件，而只是一个 setuptools 创建的调用(invoked|fabric).main()的存根）是最用户友好的，并且我认为将该存根的内容移动到在任务模块中自动生成没有任何好处（实际上看到了它的许多缺点。）

是的，这一切的重点是最终得到一个库，它可以让您在不需要任何 SSH/网络/加密部门的情况下获得任务繁重的东西 :)

bitprophet picture bitprophet 于 2012-02-22

我完全同意可执行文件上的@bitprophet 。 它使运行变得更容易。 如果有人想在他们的个人项目中使用invoke / fab以外的东西，它只是一个存根，因此您可以轻松创建自己的二进制文件（并且它可以轻松地以finalname.__main__.main ，在这种情况下，如果你愿意，你也可以只使用python -m finalname 。

dstufft picture dstufft 于 2012-02-22

+1。

kenreitz42 picture kenreitz42 于 2012-02-22

只是抛出一个想法，我认为它也更方便。 FWIW，如果你想使用它，我星期五在 PyPI 上注册了它。

tswicegood picture tswicegood 于 2012-02-22

@bitprophet抱歉，我想您知道如何使用入口点。 我以我自己的方式投票支持以类似于鼻子的方式做前端并保持名称为 fab。

dcolish picture dcolish 于 2012-02-22

想法很棒，我喜欢想法:)

星期五有点太可爱了，尽管我确实喜欢流行文化参考。 那首歌太好听了！ ：巨魔的脸：

我认为现在我将直接使用invoke作为包/项目和二进制名称。 呸！ Invoker 或 Invoked 是前者的其他可能性（即仍然使用invoke二进制文件），但我想不出任何不走直接路线的充分理由。

这个名字的主要缺点是通用性，但这是我接手或创建的每个项目的问题，在这种情况下，没有一个更具体的选项对我来说是正确的。 /理由

bitprophet picture bitprophet 于 2012-02-22

@dcolish承认，谢谢！

我还没有做出最终决定，但我认为在这一点上明智的做法是：

  • 调用是它自己的东西，拥有新的身份/“品牌”，使用invoke二进制文件，查找tasks模块等。

    • 对于仅使用 Invoke 而不是 Fabric 的用户而言，这在概念上是干净、简单的，消除了历史包袱等

  • Invoke 将 Fabric（或其他工具）可能想要使用的任何共享代码公开为公共 API
  • Fabric 继续使用fab并寻找fabfile模块，同时添加对 Invoke 的安装时依赖，并使用 Invoke 的 API 调用该共享代码

    • 这确实意味着安装 Fabric 会产生两个二进制文件，但从关注 Fabric 的用户的角度来看，他们不需要_知道_ invoke / tasks存在/是选项，因为它们' d 从不使用它们—— fab仍然是功能的超集。

    • 想要同时使用 Invoke 的用户（例如，在没有 Fabfile 的其他项目中）_and_ Fabric 是症结所在，重新： invoke和fabric如何相互关联并表现. 这些人可能对invoke和fab作为彼此的简单别名感兴趣（即让 Fabric 的安装改变invoke的行为方式，就像鼻子插件的工作方式一样。）

    • 但是，我认为最好让两者的行为有所不同—— fab _必须_在“我要查找的任务模块的名称是什么？”中区分_至少_。 从某种意义上说，此时我们还不如让它成为它自己的生物，而 Fabric 和 Invoke 之间的关系仅在于 Fabric 如何使用 Invoke 的代码库。

编辑：我应该看看_如何_这将很快奏效，然后再做任何最终决定。 实践与理论等等。 可能会遇到我在这里没有考虑的角度。

bitprophet picture bitprophet 于 2012-02-23

Invoke 现在有一个 beta 版本（经过大量最近的工作构建它）。 已经在：

  • 更好、更明确但仍然几乎是零样板命名空间
  • “真正的”CLI 标志解析器，不再是foo:bar,lol ，包括将函数 argspec 自动转换为 CLI 规范
  • 尝试将任务执行位设计为可扩展/可覆盖 re: 并行化
  • 这样做是为了支持：前置任务（指示要在其他任务之前运行的任务）
  • 具有捕获和打印功能的本地任务运行程序run （尽管在 Windows 上可能不起作用）
  • 可能会忘记另外几位？

在它上面冲刺，并希望本周开始制作 Fab 2 将如何固定在上面的原型。

bitprophet picture bitprophet 于 2013-03-18

确保清洁
确保建成
“确保”“状态”

steverweber picture steverweber 于 2013-10-22

Fabric 2 的状态如何？ 那里有一个叉子可以覆盖这个吗？ 我的意思是fabric2 应该涵盖的那些不是调用的东西。

mvaled picture mvaled 于 2014-03-24

@mvaled它很快就会出现，一直在织物回购的一个私人“干净”分支中。

bitprophet picture bitprophet 于 2014-08-04

对不起，如果这不是主题，但我不得不再次问：
我在哪里可以找到面料 2？
我真的很喜欢invoke，感觉就像是一个巨大的改进，但是invoke 1.0 版本缺少什么？ （描述为织物 2 的基础）

感谢您在调用和结构方面所做的所有出色工作！

dmr picture dmr 于 2015-01-09

@dmr我正在让 Fabric 2 在 Invoke 之上工作。 从 Fabric 1 移植的一堆功能将为 Invoke 的设计决策提供信息（对于新功能或现有功能 - 例如最近的配置大修就是其中之一），所以我不想标记 Invoke 1.0，直到它成为“实战考验”充分。

我的计划是最迟通过 PyCon 为公众准备 Fabric 2 的 alpha 版本（最好是更早），这将导致 Fabric 2.0 + Invoke 1.0。

bitprophet picture bitprophet 于 2015-01-28

谢谢你的澄清，我在哪里可以帮忙？

dmr picture dmr 于 2015-01-28

我在一个私人分支中进行短期工作，直到我得到我满意的东西，一旦我准备好接受反馈，我会在推特/邮件列表/等上宣布，所以请继续关注。

bitprophet picture bitprophet 于 2015-01-28

我开始切换到结合shell命令和一些Paramiko调用，因为fabric是我项目中最后一个不支持python3的包

dmr picture dmr 于 2015-08-13

昨天发布了 Fabric 2.0 和 Invoke 1.0 as Python 3.5 的任何 ETA，并将成为 Ubuntu 16.04 LTS 的默认设置？

tebanep picture tebanep 于 2015-09-14
👍3
此页面是否有帮助？
0 / 5 - 0 等级

相关问题

Grazfather picture Grazfather  ·  4评论
yuvadm picture yuvadm  ·  5评论
bitprophet picture bitprophet  ·  6评论
omzev picture omzev  ·  6评论
supriyopaul picture supriyopaul  ·  4评论