Fabric: Teilen Sie nicht-ssh-abhängige Funktionen in separate Bibliotheken auf

:Kuchen:

Ein völlig neues Tool, das gut zum Anwendungsfall passt, ist natürlich immer auch eine Option.

Aktualisierte Beschreibung ein Haufen.

@kennethreitz : Das wäre wirklich ein neues "Ding", nur basierend auf den bestehenden Anforderungen/Funktionen dieser Hälfte von Fabric. Die Idee ist, dass es eine eigene Einheit in Bezug auf Installation, Entwicklungsplan usw. ist, aber immer noch von den Fabric-Entwicklern / der Community kontrolliert wird.

Ideen:

• tony - wie in Tony Masters alias The Taskmaster (Comics~)
• CEO - Führt Dinge aus (oder Zar oder etwas Ähnliches in dieser Richtung)

Entschuldigung, ich scheiße auf Namen :(

Auch Dinge wie „kirk“ (wie in „captain kirk“).

Ich habe versucht, mir etwas Stoffbezogenes auszudenken, das mit Laufaufgaben zu tun hat, aber mir fällt nichts ein, das mit Aufgaben + Stoff zusammenhängt.

Aber Loom ist auch kein schlechter Name, finde ich.

Anfangsnamen-Brainstorming.

Konzepte

• Laufen/Joggen/etc
• Ausführung (von Befehlen, Leute vielleicht, obwohl das ein bisschen makaber ist usw.)
• Aufgaben (wie Erledigungen, Besorgungen usw.)
• Vielleicht einige der abgelehnten oder ähnlichen Namen aus #461, insofern die Idee, Dinge aus Stoff zu weben oder zusammenzusetzen, auch für Aufgaben gilt

Namen, die nicht auf PyPI übernommen wurden

• runner
• executor
• go
  
  
  
  • Verwirrung mit der Programmiersprache und/oder dem Brettspiel, besonders wenn ersteres eine Binärdatei namens go hat
  
  
  • Ob gut oder schlecht, hat viele potenziell dumme Aufgabennamen wie away oder fuck_yourself oder bother_somebody_else
  
  
• weaver

Binäre Namen

Danke, Oxford American Writer's Thesaurus, wie er von der Wörterbuchanwendung von OS X präsentiert wird!

• run
• execute
• go
  
  
  
  • Siehe oben
  
  
• create (wie make )
• fabricate (zu lang, zu leicht mit fab zu verwechseln)
• fab (d. h. diese neue Bibliothek anders benannt, aber immer noch eine fab -Binärdatei installieren; wenn beide auf dem System vorhanden sind, hat die Fabric-Bibliothek Vorrang? Scheint eine dumme Idee zu sein.)
• generate
• produce
• fashion (meh)
• build
• devise
• shape
• setup
• weave

Heute nicht in Bestform beim Brainstorming. Willst du mähen.

@dstufft Loom ist ein OK-Name, und CEO ist ein größtenteils OK-Konzept (kein großer Fan der Comic-Referenz, schon allein, weil es obskur erscheint, ich hatte noch nie von der Figur gehört ;)). Das Hauptproblem besteht darin, einen guten binären Namen zu finden. Ich denke, ein Verb ist so ziemlich ein Muss, damit es gut funktioniert. Ich bin mir nicht sicher, was für beide funktionieren würde.

Boss: Führt die Dinge aus.

teilnehmen. Ein bisschen wie Make, aber für Python.

Exekutive.

Ich mag die Idee, dass es sich an Aufgaben orientiert. Hmm..

@kennethreitz Ich mag Boss, abgesehen von der möglichen Verwechslung mit einem gewissen New Jerseyer (sorry, nur kein Fan, schlechte Mitbewohnererfahrung im College)

Wie ich @dstufft gesagt habe, sind binäre Namen hier definitiv der Schlüssel. Wenn Sie also können, versuchen Sie bitte, diese auch im Hinterkopf zu behalten. Ein toller Projektname hilft nicht, wenn der Projektname-als-binär irgendwie dumm klingt ;)

Dienstmädchen ist interessant. Erledigt Ihre Aufgaben für Sie. Ähnlich wie "Machen".

Butler auch. Wir könnten einen beliebigen britisch klingenden Butlernamen auswählen.

maid clean , maid release , maid test . Ich mag das.

Abgesehen davon, dass es meine (natürlich grenzenlose) Männlichkeit beeinträchtigt, ist maid ziemlich gut, auch wenn es nicht in das Verbmuster passt. (Das heißt, es ist einer der besseren Binärnamen ohne Verb.) (EDIT: und was machen Butler _do_? Butle?)

Ich habe nur den Namen besetzt, nur für den Fall. Gefällt mir bisher sehr gut.

Boss als Bibliotheksname ist FWIW bereits vergeben

Am Dienstag, den 21. Februar 2012 um 20:38 Uhr schrieb Jeff Forcier:

Abgesehen davon, dass es meine (natürlich grenzenlose) Männlichkeit beeinträchtigt, ist maid ziemlich gut, auch wenn es nicht in das Verbmuster passt. (Das heißt, es ist einer der besseren Binärnamen ohne Verb.)

---

Antworten Sie direkt auf diese E-Mail oder sehen Sie sie auf GitHub an:
https://github.com/fabric/fabric/issues/565#issuecomment -4095609

intern ist auch eine unglaublich tolle Wahl.

@dstufft So ist es, und mir ist auch kein guter binärer Name dafür eingefallen, boss docs passt nicht wirklich gut.

@kennethreitz erwähnte bake im IRC, was zum Make/Rake-Thema passt und auch irgendwie als Invoke-Verb passt (z. B. $ bake docs , obwohl es thematisch etwas daneben ist, fühlt sich so an, d passt besser in Chef oder so.

EDIT: auch deliver . Meine anfängliche Reaktion darauf war etwas positiv ( $ deliver build $ deliver docs ), aber es gibt keinen _großartigen_ Projektnamen, der dazu passt, der nicht ein bisschen zu albern ist, und er ist ein bisschen lang.

$ invoke taskname (Projektnamen: invoker , invoked , ???)

Aufgerufen.

Ich mag wirklich Invoked und invoke docs invoke tests invoke publish usw.

Der Projektname könnte auch nur "Invoke" lauten. Benötigen die Binärdatei und das Projekt unterschiedliche Namen?

Ich denke, "invoked" hat ein bisschen mehr Schwung als "invoke", aber beides könnte funktionieren.

Der Name muss sich nicht unterscheiden, nein, es ist nur so oft sinnvoller.

Ich hatte einen Gedanken, als ich zum Zug ging (in besagtem Zug jetzt :P go go Smartphone-Tethering!), und zwar, dass wir das alles möglicherweise überspringen und einfach die gesamte fab + fabfile.py -Seite verschieben könnten von Dingen in diese "neue" Bibliothek (und nennen Sie sie, sagen wir, fabricator ).

Mit anderen Worten, eine Callable für die Standalone-Bibliothek und eine andere für das SSH-Setup muss nicht unbedingt vorkommen und könnte sogar ein Nachteil sein.

Pluspunkte:

• Es ist kein neuer Binärname erforderlich
• Zwei binäre Namen zu haben, wäre sowieso verwirrend
• Wenn die neue Lib _nicht_ "fabfiles" verwenden würde, hätten wir auch zwei verschiedene "Aufgabendatei"-Typen, wieder verwirrend/zusätzlicher Code/etc

Minuspunkte:

• Mögliche Verwechslung zwischen den beiden Projekten aufgrund ähnlicher Namen
• Ein neues Projekt müsste besonders erweiterbar sein, damit alle Fabric-Ismen (z. B. fast alle CLI-Flags usw.) unverändert weiterarbeiten können
  
  
  
  • Dh pip install fabricator gibt uns fab , was einen kleineren Satz von Flags hätte
  
  
  • Wenn Sie dann pip install fabric verwenden, muss dasselbe fab plötzlich alle zusätzlichen Fabric-CLI-Flags anzeigen, wenn nicht auch noch andere Dinge
  
  
  • OTOH, es ist nicht so, dass es eine _schlechte_ Sache wäre, "Client"-Code zu erlauben, das CLI-Parsing zu erweitern, es ist nur mehr Arbeit, die im Voraus erledigt werden muss.
  
  

Sie können einen Befehlszeilen-Client erweiterbar machen. Sehen Sie sich an, wie Nose es ermöglicht, Plugin-Einstiegspunkte über sein Befehlszeilentool auszudrücken

Ich denke, die zusätzliche Erweiterbarkeit wäre eine gute Sache, egal in welche Richtung es geht.

Die Namensverwechslung wäre ein Problem, denke ich.

Das ist eine persönliche Sache, aber mir gefällt das Aussehen von invoke test invoke docs besser als fab test .

Was die verschiedenen Binärdateien angeht, würde ich nur sicherstellen, dass die Kernbinärdatei (invoke) erweiterbar ist, damit alle Fabric-Dinge passieren können, und dann fab einfach denselben Einstiegspunkt wie invoke aufrufen (dh die eigentlichen fab/invoke-Binärdateien wären nur ultra-minimalistische Aufrufer eines main() (oder was auch immer).

Ich würde denken, wenn Sie die Invoke + Fabric-Route gehen, die sowohl Fabfiles als auch "Invokefiles" vor 2.0 enthält? würde unterstützt werden, und dann mit 2.0 nur Dateien aufrufen?

Im Wesentlichen bin ich also +1, weil ich es in verschiedene "Task Runner" und "Remote / SSH-Sachen" aufgeteilt habe, Compat-Shims für 1.x eingefügt und Sachen für 2.x abgelehnt habe. Diese Aufteilung würde meiner Meinung nach beide Bibliotheken verbessern, der Task-Runner würde eine wirklich nette Erweiterbarkeit unterstützen (und wahrscheinlich externe Tasks, auf die man sich leicht verlassen kann, die ausgeführt werden usw.). Und das Remote-/SSH-Zeug würde davon profitieren, weniger Verantwortlichkeiten zu haben, die es ermöglichen, fokussierter zu sein/

Meine Cent sowieso.

Ich sollte klarstellen, dass ich den anderen Weg nicht hasse, ich bin froh, dass diese Diskussion überhaupt stattfindet :)

@dstufft Vielen Dank für die Gedanken, dem stimme ich so ziemlich zu. Sie haben Recht damit, dass die Binärdateien nur Stubs sind. So funktioniert Fabric jetzt. Meine Sorge gilt ausschließlich dem Verhalten und der Verwirrung der Benutzer.

@dcolish Ich wollte nicht andeuten, dass es nicht möglich ist, die CLI-Erweiterungen durchzuführen, und die Nase ist definitiv ein guter Stand der Technik, um sie zu untersuchen.

Wenn wir mit "invoke" gehen, könnte der Dateiname vielleicht invocations(.py) sein? Ein bisschen albern/Themenpark, aber grammatikalisch passt es, und invokefile.py fühlt sich für mich ein bisschen komisch an. Oder gehen Sie möglicherweise den Weg der Rake-Convention und verwenden Sie einfach tasks(.py) .

Teilweise verwandt, denke ich, dass wir uns in Zukunft auch definitiv auf den Modul-/Ordneraspekt konzentrieren sollten. Da es sich um Just Python handelt, wird beides weiterhin unterstützt, aber in Bezug auf Tutorial-Material und Dokumentation könnte es eine gute Sache sein, invocations/__init__.py als Standard zu verwenden.

Ich mag tasks.py . invocations.py ist komisch zu tippen.

Nun, es ist nicht so, dass Sie es sehr häufig tippen müssten, oder? ;) Aber ja, tasks/ oder tasks.py ist global etwas offensichtlicher.

taskfile.py

Sie invoke Aufgaben (.py|/), die Formulierung ist sowieso schön :)

Ja, das „Das sind tasks was Sie invoke “-Setup funktioniert sehr gut aus der Perspektive, die Schlüsselwörter mit englischen Beschreibungen zu verknüpfen, wie es funktioniert. Es ist offensichtlich, kein Schnickschnack, keine Einbildung usw.

@kennethreitz Ich war nie wirklich ein großer Fan von XYZFile als Namenskonvention, und besonders da es heutzutage häufig _keine_ einzelne Datei ist, sehe ich keine Notwendigkeit, die Konvention außerhalb von Fab 1.x fortzusetzen :)

Ich würde das total gerne sehen. Ich habe Fabric immer als eine generische pythonische Methode zum Speichern von "Aufgaben" für ein Projekt angesehen, unabhängig davon, ob sie lokal oder ferngesteuert sind, etwas näher an Rake/Make. Bei dem Versuch, neue Leute vorzustellen, waren jedoch einige Leute verwirrt und betrachteten es nur als Bereitstellungstool.

Ich würde den Modul/Ordner-Aspekt unterstützen, um es einfacher zu machen, generische Aufgaben zu erstellen, die Drop-in-fähig sind. Aufgaben im neuen Stil gingen definitiv gut in diese Richtung.

@askedrelic Yup , es war leider immer etwas verwirrend, dass es zwei Dinge in einem waren.

Ohne Bezug: Ich rufe @tswicegood zu diesem Thread, da er und ich das Thema vor ein paar Wochen besprochen haben, und ich denke, er möchte sich vielleicht einmischen. Wie üblich behalte ich mir das Recht vor, anderer Meinung zu sein ;)

Ich wurde gerufen? :-)

Ich mag die Idee, zu tasks als Modul statt zu fabfile . Macht mehr Sinn und ist kürzer. Ich für meinen Teil hasse es, den vollständigen Dep-Stack installieren zu müssen, nur um fab test in Armstrong ausführen zu können, also alles, was getan werden könnte, um zu extrahieren, dass ich ein großes Plus bin.

Was die Benennung betrifft, wie wäre es, wenn Sie von einer externen ausführbaren Datei, die installiert ist, darauf umstellen, dass die Leute dies unten hinzufügen:

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

Dann verwenden Sie einfach Python. Ich bin mit einer ausführbaren Datei einverstanden, weiß nur nicht, ob es notwendig ist.

FWIW, ich habe vor ein paar Wochen ein Projekt namens flunky gestartet, um die Paketerstellung zu handhaben. Um bei diesem begleitenden Thema zu bleiben, sind footman oder lacky beide verfügbar (letzteres hat einen Konflikt mit lackie – einem Ruby-Projekt). Ein anderer wäre Freitag, wie in girl/man friday . Es besteht den GitHub/PyPI/Homebrew-Test, da es nichts mit diesem Namen gibt. Eigentlich wäre das jetzt, wo ich darüber nachdenke, meine erste Wahl.

Nebenwette, ich frage mich, wie lange es dauern würde, bis @niran eine PR-Aktualisierung der README einreichte, um den offensichtlichen, wenn auch schrecklichen Titelsong aufzunehmen.

Ich denke, eine On-Your- $PATH "Binärdatei" zu haben (insbesondere angesichts der Tatsache, dass es derzeit _keine_ echte Binärdatei ist, sondern nur ein von Setuptools erstellter Stub, der (invoked|fabric).main() aufruft) ist am benutzerfreundlichsten , und ich sehe keine Vorteile darin, den Inhalt dieses Stubs zu verschieben, damit er innerhalb des Aufgabenmoduls automatisch generiert wird (und sehe tatsächlich eine Reihe von Nachteilen).

Und ja, der ganze Sinn dahinter ist, am Ende eine Lib zu haben, mit der Sie das aufgabenhafte Zeug bekommen können, ohne SSH-/Netzwerk-/Krypto-Deps zu benötigen :)

Ich stimme @bitprophet bezüglich der ausführbaren Datei vollkommen zu. Es macht es viel einfacher zu laufen. Wenn jemand etwas anderes als invoke / fab für sein persönliches Projekt verwenden möchte, ist es nur ein Stub, sodass Sie problemlos Ihre eigene Binärdatei erstellen können (und sie könnte problemlos bei finalname.__main__.main leben , in diesem Fall könnten Sie auch nur python -m finalname , wenn Sie wollten.

+1.

Einfach eine Idee rauswerfen, finde ich auch bequemer. FWIW, ich habe mich am Freitag auf PyPI registriert, wenn Sie es verwenden möchten.

@bitprophet Entschuldigung, ich dachte, Sie wüssten, wie man Einstiegspunkte verwendet. Ich habe auf meine Weise dafür gestimmt, ein Frontend ähnlich wie bei Nose zu machen und den Namen fabelhaft zu lassen.

Ideen sind toll, ich liebe Ideen :)

Der Freitag ist ein bisschen zu süß, obwohl ich den Bezug zur Popkultur mag. Das Lied ist so toll! :Troll Gesicht:

Ich denke, im Moment verwende ich invoke sowohl als Paket-/Projekt- als auch als Binärnamen. Juhu! Invoker oder Invoked waren andere Möglichkeiten für Ersteres (dh immer noch mit einer invoke -Binärdatei), aber mir fiel kein guter Grund ein, nicht den direkten Weg zu gehen.

Der Hauptnachteil dieses Namens ist die Allgemeinheit, aber das ist ein Problem bei jedem Projekt, das ich je übernommen oder erstellt habe, und in diesem Fall fühlte sich keine der spezifischeren Optionen für mich richtig an. /Rechtfertigung

@dcolish Bestätigt, danke!

Ich habe noch keine endgültige Entscheidung getroffen, aber ich denke, an dieser Stelle ist der vernünftige Ansatz:

• Invoke ist eine eigene Sache, eigene neue Identität/"Marke", verwendet invoke binär, sucht nach tasks -Modul usw.
  
  
  
  • Dies ist sauber, konzeptionell unkompliziert für Benutzer, die nur Invoke und nicht Fabric verwenden, entfernt historischen Ballast usw
  
  
• Invoke macht jeden gemeinsam genutzten Code, den Fabric (oder andere Tools) möglicherweise verwenden möchten, als öffentliche APIs verfügbar
• Fabric verwendet weiterhin fab und sucht nach einem fabfile -Modul, während es eine Installationsabhängigkeit von Invoke hinzufügt und die APIs von Invoke verwendet, um diesen gemeinsam genutzten Code aufzurufen
  
  
  
  • Das bedeutet, dass die Installation von Fabric zu zwei Binärdateien führt, aber aus der Perspektive von Benutzern, die sich auf Fabric konzentrieren, müssen sie nicht _wissen_, dass invoke / tasks Optionen existieren/sind, weil sie Ich würde sie nie verwenden -- fab ist immer noch eine Obermenge an Funktionalität.
  
  
  • Benutzer, die sowohl Invoke um seiner selbst willen (z. B. in anderen Projekten, die keine Fabfiles haben) _und_ Fabric verwenden möchten, sind der Knackpunkt, bezüglich: wie sich invoke und fabric zueinander verhalten und verhalten . Diese Leute könnten ein gewisses Interesse daran haben, dass invoke und fab einfache Aliase voneinander sind (d. h., dass die Installation von Fabric mutiert, wie sich invoke verhält, wie etwa Nose-Plugins funktionieren).
  
  
  • Ich denke jedoch, dass es am besten ist, wenn sich die beiden unterschiedlich verhalten – fab _muss_ _mindestens_ in der Frage "nach welchem ​​Namen des Aufgabenmoduls soll ich suchen?" unterscheiden. An diesem Punkt können wir es genauso gut als eigene Kreatur haben, und die Beziehung zwischen Fabric und Invoke besteht nur darin, wie Fabric die Codebasis von Invoke verwendet.
  
  

BEARBEITEN: Ich sollte einen Blick darauf werfen, wie das funktioniert, schnell, bevor ich irgendetwas endgültig mache. Praxis gegen Theorie und so weiter. Kann in Winkel geraten, an die ich hier nicht denke.

Invoke hat jetzt eine Beta-Version (nach viel Arbeit in letzter Zeit beim Aufbau). Bereits in:

• Besseres, expliziteres, aber immer noch nahezu null Boilerplate-Namespaces
• "Echter" CLI-Flag-Parser, nicht mehr foo:bar,lol , einschließlich automatischer Übersetzung der Funktion argspec in die CLI-Spezifikation
• Es wurde versucht, Aufgabenausführungsbits so zu gestalten, dass sie erweiterbar/überschreibbar sind bezüglich: Parallelisierung
• Was getan wurde, um Folgendes zu unterstützen: Voraufgaben (geben Aufgaben an, die vor anderen Aufgaben ausgeführt werden sollen)
• Capture-and-Print-fähiger lokaler Task-Runner run (obwohl wahrscheinlich nicht unter Windows funktionsfähig)
• Vielleicht vergisst du noch ein paar Bits?

Darauf sprinten und hoffen, diese Woche mit dem Prototyping zu beginnen, wie Fab 2 darauf geschraubt wird.

sauber sorgen
sicher gebaut
"sicherstellen" "angeben"

Wie ist der Status von Fabric 2? Gibt es da draußen einen Fork, der das abdeckt? Ich meine das Zeug, das fabric2 abdecken sollte, das nicht aufgerufen wird.

@mvaled Es wird in Kürze erscheinen, war in einem privaten "sauberen" Zweig des Fabric-Repos.

Entschuldigung, wenn dies nicht zum Thema gehört, aber ich muss nochmal fragen:
Wo finde ich Stoff 2?
Ich mag Invoke wirklich und es fühlt sich wie eine riesige Verbesserung an, aber was fehlt für eine Version von Invoke 1.0? (beschrieben als Grundlage für Stoff 2)

Danke für all die tolle Arbeit an Invoke und Fabric!

@dmr Ich bin gerade dabei, Fabric 2 auf Invoke zum Laufen zu bringen. Eine Reihe von Features, die von Fabric 1 portiert werden sollen, werden Designentscheidungen für Invoke beeinflussen (für neue Features oder vorhandene - z. kampferprobt" ausreichend.

Mein Plan ist es, spätestens bis PyCon (idealerweise viel früher) eine Alpha von Fabric 2 für die Öffentlichkeit bereit zu haben, und das wird zu Fabric 2.0 + Invoke 1.0 führen.

Danke für die Klarstellung, wo kann ich helfen?

Ich arbeite kurzfristig in einem privaten Zweig daran, bis ich etwas bekomme, mit dem ich zufrieden bin, und werde es auf Twitter/Mailingliste/etc ankündigen, sobald ich bereit für Feedback bin, also bleiben Sie bitte dran.

Ich fing an, in Kombination mit Shell-Befehlen und etwas Paramiko auf Invoke umzusteigen, weil Fabric das letzte Paket ohne Python3-Unterstützung in meinem Projekt ist

Jede ETA für Fabric 2.0 und Invoke 1.0 als Python 3.5 wurde gestern veröffentlicht und wird die Standardeinstellung in Ubuntu 16.04 LTS sein?