Fabric: sshに依存しない機能を個別のライブラリに分割する

：ケーキ：

もちろん、ユースケースにうまく適合するまったく新しいツールも常にオプションです。

説明をたくさん更新しました。

@kennethreitz ：これは、Fabricのその半分の既存のニーズ/機能セットに基づいた、実際には新しい「もの」になるでしょう。 アイデアは、インストール、開発スケジュールなどの独自のエンティティでありながら、Fabricの開発者/コミュニティによって制御されることです。

アイデア：

• トニー-トニーマスター、別名タスクマスター（漫画本〜）のように
• CEO-物事を実行します（またはその線に沿って皇帝または同様のもの）

申し訳ありませんが、私は名前を吸います:(

また、「カーク」（キャプテンカークのように）のようなもの。

タスクの実行に関係するファブリック関連の何かを考えようとしましたが、タスク+ファブリックに関連するものは考えられません。

しかし、Loomも悪い名前ではないと思います。

頭文字のブレインストーミング。

コンセプト

• ランニング/ジョギングなど
• 実行（注文の実行、おそらくそれは少し気味が悪いですが、人々など）
• タスク（やること、用事など）
• おそらく、＃461から拒否された、または類似した名前のいくつかは、ファブリックから物を織り込んだりまとめたりするというアイデアがタスクにも当てはまる限りです。

PyPIで使用されていない名前

• runner
• executor
• go
  
  
  
  • プログラミング言語やボードゲームとの混同、特に前者が特にgoと呼ばれるバイナリを持っている場合
  
  
  • 良くも悪くも、 awayまたはfuck_yourselfまたはbother_somebody_elseなどの多くの潜在的なばかげたタスク名があります
  
  
• weaver

バイナリ名

おかげで、OS Xの辞書アプリケーションによって提示されたオックスフォードアメリカンライターのシソーラス！

• run
• execute
• go
  
  
  
  • 上記を参照
  
  
• create （ makeなど）
• fabricate （長すぎる、 fabと簡単に混同される）
• fab （つまり、この新しいlibの名前は異なりますが、 fabバイナリをインストールします。両方がシステムに存在する場合は、Fabricの方が優先されますか？ばかげた考えのようです。）
• generate
• produce
• fashion （meh）
• build
• devise
• shape
• setup
• weave

今日、最高のブレインストーミング形式ではありません。 うめき声が欲しい。

@dstufft Loomは大丈夫な名前であり、CEOはほとんど大丈夫な概念です（漫画本のリファレンスの大ファンではありませんが、それがあいまいに見えるという理由だけで、私はそのキャラクターのことを聞いたことがありません;））。 主な問題は、適切なバイナリ名を考え出すことです。動詞がうまく機能するには、動詞がほぼ必須であるように感じます。 それらのどちらでも何がうまくいくかわからない。

上司：物事を実行します。

参加する。 Makeのようなものですが、Python用です。

エグゼクティブ。

私はそれがタスクを中心に据えるという考えが好きです。 うーん..

@kennethreitz私はボスが好きですが、特定のニュージャージーのネイティブとの潜在的な混乱を除いて（申し訳ありませんが、ファンではなく、大学での悪いルームメイトの経験）

@dstufftに言ったように、ここではバイナリ名が間違いなく重要なので、可能であれば、それらも念頭に置いてください。 優れたプロジェクト名は、project-name-as-binaryがちょっとばかげているように聞こえる場合は役に立ちません;）

メイドさんがおもしろいです。 あなたのためにあなたのタスクを実行します。 「作る」に似ています。

バトラーも。 英国風の執事の名前をランダムに選ぶことができます。

maid clean 、 maid release 、 maid test 。 それはいいですね。

私の（無限の、自然な）男らしさに影響を与えることを除けば、 maidは動詞のパターンに適合していなくても、かなり良いです。 （つまり、動詞以外の優れたバイナリ名の1つです。）（編集：バトラーは何をしますか？バトラー？）

念のため、名前をしゃがんだだけです。 今のところとても気に入っています。

ライブラリ名としてのボスはすでにFWIWになっています

2012年2月21日火曜日の午後8時38分、JeffForcierは次のように書いています。

私の（無限の、自然な）男らしさに影響を与えることを除けば、 maidは動詞のパターンに適合していなくても、かなり良いです。 （つまり、動詞以外の優れたバイナリ名の1つです。）

---

このメールに直接返信するか、GitHubで表示してください。
https://github.com/fabric/fabric/issues/565#issuecomment -4095609

internも信じられないほど素晴らしい選択です。

@dstufftそうです、そして私もそのための良いバイナリ名を考えることができませんでした、 boss docsは本当にうまく適合しません。

@kennethreitzは、IRCでbakeについて言及しました。これは、make / rakeテーマに適合し、invoke動詞としても適合します（たとえば、 $ bake docsは、テーマ的には少しずれていますが、そのように感じます」 dシェフか何かによく合います。

編集： deliverも。 これに対する私の最初の反応はやや肯定的でした（ $ deliver build $ deliver docs ）が、それに伴う_素晴らしい_プロジェクト名は少しばかげていませんし、少し長いです。

$ invoke taskname （プロジェクト名： invoker 、 invoked 、???）

呼び出されました。

Invokedやinvoke docs invoke tests invoke publishなどが本当に好きです。

プロジェクト名も「Invoke」にすることができますが、バイナリとプロジェクトには異なる名前が必要ですか？

「invoked」は「invoke」よりも少しピザが多いと思いますが、どちらでも機能する可能性があります。

名前は異なる必要はありません、いいえ、それはそれがより理にかなっている回数だけです。

電車に向かって歩いているときに考えました（電車の中で：P go go smart tethering！）これは、おそらくこれをすべてスキップして、 fab + fabfile.py側全体を移動するだけでよいということです。この「新しい」ライブラリに物事を追加します（たとえば、 fabricatorと呼びます）。

言い換えると、スタンドアロンlib用に1つ呼び出し可能で、SSHを使用するセットアップ用に別の呼び出し可能であることが必ずしも発生する必要はなく、不利益になる可能性さえあります。

プラス：

• 新しいバイナリ名は必要ありません
• 2つのバイナリ名があると、とにかく混乱します
• 新しいlibが「fabfiles」を使用しない場合、2つの異なる「タスクファイル」タイプもあり、これも混乱を招きます/余分なコードなどです

マイナス：

• 類似した名前による2つのプロジェクト間の潜在的な混乱
• 新しいプロジェクトは、すべてのファブリックイズム（たとえば、ほとんどすべてのCLIフラグなど）がそのまま機能し続けることができるように、さらに拡張可能である必要があります。
  
  
  
  • つまり、 pip install fabricatorはfabを提供します。これには、いくつかの小さいフラグのセットが含まれます。
  
  
  • 次に、 pip install fabricの場合、突然同じfabが、他のものではないにしても、すべての追加のファブリックCLIフラグを表示する必要があります。
  
  
  • OTOH「クライアント」コードがCLI解析を拡張できるようにするのは_悪い_ことではなく、前もって行わなければならない作業が増えるだけです。
  
  

コマンドラインクライアントを拡張可能にすることができます。 noseがプラグインエントリポイントをコマンドラインツールから表現する方法を見てください

どちらの方向に進んでも、拡張性を高めることは良いことだと思います。

名前の混乱は私が思うに問題になるでしょう。

これは個人的なことですが、 fab test $よりも$ invoke test invoke docsの見た目が好きです。

さまざまなバイナリに関する限り、コアバイナリ（invoke）が拡張可能であり、すべてのファブリックが発生することを確認してから、fabにinvokeと同じエントリポイント（つまり、実際のfab /invokeバイナリ）を呼び出すようにします。 main() （またはその他）の超ミニマルな呼び出し元になります。

2.0より前のfabfilesと"Invokefiles"の両方を呼び出す+ファブリックルートを使用すると思いますか？ サポートされ、2.0ではファイルを呼び出すだけですか？

つまり、基本的に私はそれを別個の「タスクランナー」と「リモート/ SSHのもの」に分割し、1.xの場合は互換性のあるシムを入れ、2.xの場合は非推奨にすることで+1です。 この分割により、両方のライブラリが改善され、タスクランナーは、いくつかの非常に優れた拡張性（および、簡単に依存、実行などできる外部タスク）をサポートすると思います。 そして、リモート/ SSHのものは、より小さな責任のセットを持つことで利益を得ることができ、より集中することができます/

とにかく私のセント。

私は他の方法を嫌いではないことを明確にする必要があります、私はこの議論がまったく起こっていることを嬉しく思います:)

@dstufft考えてくれてありがとう、私はそのほとんどすべてに同意します。 あなたはバイナリが単なるスタブであることについて正しいです、それが現在Fabricがどのように機能するかです、私の懸念は単に振る舞いとユーザーの混乱についてです。

@dcolish CLI拡張機能を実行できないことを意味するつもりはありませんでした。また、noseは確かに検討するのに適した先行技術です。

「invoke」を使用する場合、ファイル名はinvocations(.py)である可能性がありますか？ 愚かな/テーマパーク側のタッチですが、文法的には適合し、 invokefile.pyは私には少しぎこちなく感じます。 または、Rakeコンベンションルートに行き、 tasks(.py)を使用することもできます。

部分的に関連して、私たちはまた、今後、モジュール/フォルダーの側面に間違いなくハミング/焦点を当てるべきだと思います。 ただのPythonなので、どちらも引き続きサポートされますが、チュートリアルの資料とドキュメントの観点からは、 invocations/__init__.pyをデフォルトにするのは良いことかもしれません。

私はtasks.pyが好きです。 invocations.pyは入力するのがおかしいです。

頻繁に入力しなければならないというわけではありませんね。 ;）しかし、はい、 tasks/またはtasks.pyはもう少しグローバルに明白です。

taskfile.py

あなたはinvokeタスク（.py | /）、とにかく言葉遣いはいいです:)

ええ、「これらはtasksです。 invoke 」の設定は、キーワードを英語の説明と結び付けるという観点からは非常にうまく機能します。 それは明らかで、飾り気がなく、うぬぼれもありません。

@kennethreitz命名規則としてXYZFileの大ファンになったことがないので、特に最近は単一のファイルではないことが多いので、Fab1.xの外で規則を続ける必要はないと思います:)

私はこれが起こるのを見たいと思っています。 私は常に、Fabricを、プロジェクトの「タスク」をローカルベースかリモートベースかに関係なく、Rake/Makeに近いものに格納するための一般的なPythonの方法と見なしてきました。 しかし、新しい人々を紹介しようとすると、何人かの人々はこの観点に混乱し、それを展開ツールとしてのみ見ました。

ドロップイン可能な一般的なタスクを簡単に作成できるようにするために、モジュール/フォルダーの側面を2番目にします。 新しいスタイルのタスクは間違いなくそれに向けて良い方法でした。

@askedrelicうん、それを2つのものにすることは残念ながらいつも少し混乱してきました。

無関係：彼と私が数週間前にこの問題について話し合っていたので、私はこのスレッドに@tswicegoodを召喚し、彼が加重したいと思うかもしれないと思います。いつものように、私は同意しない権利を留保します;）

召喚された？ :-)

fabfileではなく、モジュールとしてtasksに移行するというアイデアが好きです。 より理にかなっており、より短いです。 私は、1つには、アームストロング内でfab testを実行できるようにするためだけに、完全なdepスタックをインストールする必要があることを嫌います。

名前付けに関しては、外部実行可能ファイルをインストールすることから、人々にこれを下部に追加させることへの移行についてはどうでしょうか。

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

次に、Pythonを使用します。 実行可能ファイルは大丈夫ですが、必要かどうかはわかりません。

FWIW、私は数週間前にflunkyというパッケージ作成を処理するプロジェクトを開始しました。 その付随するテーマに固執して、 footmanまたはlackyの両方が利用可能です（後者はlackie -Rubyプロジェクトと競合します）。 もう1つは、女の子/男性の金曜日のように、金曜日になります。 GitHub / PyPI / Homebrewテストに合格し、その名前は何もありません。 実は、今考えてみると、それが私の最初の選択になります。

ちなみに、 @ niranがREADMEを更新するPRを提出して、明白ではあるが恐ろしいテーマソングが含まれるようになるまで、どれくらいかかるのだろうか。

$PATHの「バイナリ」（特に、現在は実際のバイナリではなく、setuptoolsで作成された(invoked|fabric).main()を呼び出すスタブ）を使用するのが最もユーザーフレンドリーだと思います。 、そしてそのスタブのコンテンツをタスクモジュール内で自動生成するように移動することにメリットはありません（実際、それにはいくつかの欠点があります）。

そして、はい、これの全体的なポイントは、SSH / network /cryptodepsを必要とせずにタスクの多いものを取得できるlibになってしまうことです:)

実行可能ファイルの@bitprophetに完全に同意します。 実行がはるかに簡単になります。 誰かが自分のプロジェクトでinvoke / fab以外のものを使用したい場合、それは単なるスタブなので、独自のバイナリを簡単に作成できます（そして、 finalname.__main__.mainで簡単に使用できます）。 、この場合、必要に応じてpython -m finalnameだけでもかまいません。

+1。

アイデアを投げかけるだけで、もっと便利だと思います。 FWIW、金曜日にPyPIを使用したい場合は、PyPIに登録しました。

@bitprophet申し訳ありませんが、エントリポイントの使用方法についてはご存知だと思います。 私は自分なりの方法で、ノーズに似た方法でフロントエンドを実行し、名前をfabとして維持することに投票していました。

アイデアは素晴らしいです、私はアイデアが大好きです:)

ポップカルチャーのリファレンスは好きですが、金曜日もかわいらしい面が少しあります。 その歌はとても素晴らしいです！ ：ドヤ顔：

今のところ、パッケージ/プロジェクトとバイナリの名前の両方として、 invokeをまっすぐに使用すると思います。 ヨインク！ InvokerまたはInvokedは、前者の他の可能性でした（つまり、まだinvokeバイナリを使用しています）が、単純なルートに進まない正当な理由は考えられませんでした。

この名前の主な欠点は一般性ですが、これは私がこれまでに引き継いだり作成したりしたすべてのプロジェクトで問題になります。この場合、より具体的なオプションはどれも私には正しく感じられませんでした。 /正当化

@dcolish承知しました、ありがとう！

私はまだ最終決定を下していませんが、現時点で賢明なアプローチは次のとおりだと思います。

• Invokeは独自のものであり、独自の新しいID /「ブランド」であり、 invokeバイナリを使用し、 tasksモジュールを検索します。
  
  
  
  • これは、FabricではなくInvokeのみを使用しているユーザーにとって、概念的にはクリーンでわかりやすく、過去の手荷物を削除します。
  
  
• Invokeは、Fabric（または他のツール）が使用する可能性のある共有コードをパブリックAPIとして公開します
• Fabricは引き続きfabを使用し、 fabfileモジュールを探しますが、インストール時の依存関係をInvokeに追加し、InvokeのAPIを使用してその共有コードを呼び出します
  
  
  
  • これは、Fabricをインストールすると2つのバイナリが生成されることを意味しますが、Fabricに焦点を当てているユーザーの観点からは、 invoke / tasksがオプションであるかどうかを_知る必要はありません。 d決してそれらを使用していません- fabはまだ機能のスーパーセットです。
  
  
  • Invokeをそれ自体のために使用したいユーザー（たとえば、Fabfileを持たない他のプロジェクト）_と_ Fabricが問題になります。つまり、 invokeとfabricが互いにどのように関係し、動作するかです。 。 これらの人々は、 invokeとfabが互いの単純なエイリアスであることに関心があるかもしれません（つまり、Fabricのインストールにより、Noseプラグインの動作のようにinvokeの動作が変化します）。
  
  
  • ただし、2つの動作を変えるのが最善だと思います。「タスクモジュールの名前を探す」では、少なくともfabを区別する必要があります。 センス、その時点でそれはそれ自身の生き物であるかもしれません、そしてFabricとInvokeの関係はFabricがInvokeのコードベースをどのように使用するかにのみあります。
  
  

編集：最終的なものを作成する前に、これがどのように機能するかをすばやく確認する必要があります。 実践対理論とそのすべて。 私がここで考えていない角度にぶつかるかもしれません。

Invokeには現在ベータリリースがあります（最近の多くの作業がそれを構築した後）。 すでに：

• より良く、より明確ですが、それでもボイラープレートの名前空間はほとんどありません
• 「実際の」CLIフラグパーサー、関数argspecからCLI仕様への自動変換を含むfoo:bar,lolは不要
• タスク実行ビットを拡張可能/オーバーライド可能に設計しようとしました：並列化
• これは、次をサポートするために行われました：プレタスク（他のタスクの前に実行されるタスクを示します）
• キャプチャおよび印刷対応のローカルタスクランナーrun （Windowsではおそらく機能しませんが）
• 別のいくつかのビットを忘れている可能性がありますか？

今週、それに全力疾走し、Fab2がどのようにそれにボルトで固定されるかをプロトタイピングし始めることを望んでいます。

清潔を確保する
構築されていることを確認してください
「確認する」「状態」

ファブリック2のステータスはどうなっていますか？ これをカバーしているフォークはありますか？ つまり、fabric2がカバーすべきもので、呼び出されないものです。

@mvaledまもなく表示され、ファブリックリポジトリのプライベートな「クリーン」ブランチにあります。

これがトピックから外れている場合は申し訳ありませんが、私はもう一度質問する必要があります：
ファブリック2はどこにありますか？
私はinvokeが本当に好きで、大幅な改善のように感じますが、invoke 1.0リリースには何が欠けていますか？ （ファブリック2の基礎として説明されています）

インボークとファブリックに関するすべての素晴らしい作業に感謝します！

@dmrInvoke上でFabric2を動作させている最中です。 Fabric 1から移植される一連の機能は、Invokeの設計上の決定を通知します（新しい機能または既存の機能の場合-たとえば、最近の構成のオーバーホールはこれらの1つでした）。十分にテストされた戦い」。

私の計画は、遅くとも（理想的にはもっと早く）PyConによってFabric 2のアルファ版を公開する予定であり、それがFabric 2.0 +Invoke1.0につながるでしょう。

明確化していただきありがとうございます、どこで私は助けることができますか？

満足のいくものが得られるまで、短期的にはプライベートブランチで取り組んでおり、フィードバックの準備ができ次第、ツイッターやメーリングリストなどで発表しますので、ご期待ください。

ファブリックは私のプロジェクトでpython3をサポートしていない最後のパッケージであるため、シェルコマンドといくつかのParamikoを組み合わせて呼び出すように切り替え始めました

Python3.5が昨日リリースされたFabric2.0およびInvoke1.0のETAは、Ubuntu 16.04 LTSのデフォルトになりますか？