16

私はpexpectに出くわしました、そして私の印象はそれが生地に大体似ているということです。私はいくつかの比較を見つけようとしましたが、成功しませんでした。そこで、誰かが両方のツールの経験がある場合に備えて、ここで質問します。

私の印象（それらはほぼ同等であるという）は正しいですか、それとも表面上はそれがどのように見えるかです。

4

3 に答える 3

15

私は両方を使用しました。 Fabricは pexpect よりも高レベルであり、IMHO の方がはるかに優れています。何に使用するかによって異なりますが、ソフトウェアの展開と構成を使用する場合は、Fabric が最適です。

于 2010-11-17T00:06:25.707 に答える
6

それらを組み合わせて、ファブリックのリモーティング機能とプロンプトの pexpects 処理の両方の長所を活用することもできます。これらの回答をご覧ください: https://stackoverflow.com/a/10007635/708221およびhttps://stackoverflow.com/a/9614913/708221

于 2012-04-04T08:50:02.800 に答える
5

どちらにも異なるユースケースがあります。pexpect が行い、Fabric が行わないことは、状態を保持することです。各 Fabric api コマンド (例: run/sudo) は、独自の個別のコマンドです。したがって、次のようにします。

run("cd project_dir && workon project")
run("make")

これはそのディレクトリにも仮想環境にもありません。現在、Fabric には cd() のコンテキスト マネージャーがありますが、各実行の先頭に多かれ少なかれ cd を追加しています。

物事のスキームでは、これはプロジェクトの大部分がどのように機能するかにはほとんど関係がなく、本質的に気付かれません. ただし、いくつかのニーズでは、複数の sudo や、フラグで自動化できないある種のインタラクティブなタスクのために、この状態を管理するために pexpect を使用することがあります。

ただし、これはすべて Fabric のデメリットではありません。Python のみであるため、fabric タスク内に pexpect コードを含めることができます。

他のすべての方法ではありますが、Fabric は基本的に、pexpect を使用してゼロからコードを作成するよりも、リモート接続とコマンドの実行のすべてのハードワークを適切に管理します。

更新Fabric と pexepect で動作するプロジェクトについて通知を受けました。詳細については、この質問の回答を参照してください。

于 2012-03-27T18:06:53.700 に答える