Fabric: Séparez les fonctionnalités non dépendantes de ssh dans une bibliothèque distincte

:gâteau:

Un outil totalement nouveau qui conviendrait bien au cas d'utilisation est toujours une option, bien sûr.

Description mise à jour un tas.

@kennethreitz : ce serait vraiment un peu une nouvelle "chose", juste basée sur les besoins/fonctionnalités existants de cette moitié de Fabric. L'idée est qu'il soit sa propre entité concernant l'installation, le calendrier de développement, etc., mais toujours contrôlé par les développeurs/la communauté Fabric.

Idées :

• tony - comme dans Tony Masters alias The Taskmaster (bandes dessinées ~)
• PDG - Gère les choses (ou tsar ou quelque chose de similaire dans ce sens)

Désolé je suis nul avec les noms :(

Aussi des choses comme "kirk" (comme dans le capitaine kirk).

J'ai essayé de penser à quelque chose lié au tissu qui a à voir avec l'exécution de tâches, mais je ne peux pas en penser à un qui soit lié aux tâches + tissu.

Mais Loom n'est pas un mauvais nom non plus je ne pense pas.

Remue-méninges sur le nom initial.

Notions

• Course à pied/jogging/etc.
• Exécution (des ordres, des gens peut-être même si c'est un peu macabre, etc.)
• Tâches (comme dans les choses à faire, les courses, etc.)
• Peut-être que certains des noms rejetés ou similaires de # 461, dans la mesure où l'idée de tisser ou d'assembler des choses à partir de tissu s'applique également aux tâches

Noms non pris sur PyPI

• runner
• executor
• go
  
  
  
  • Confusion avec le langage de programmation et/ou le jeu de société, surtout si le premier a un binaire spécifiquement appelé go
  
  
  • Pour le meilleur ou pour le pire, a de nombreux noms de tâches stupides potentiels tels que away ou fuck_yourself ou bother_somebody_else
  
  
• weaver

Noms binaires

Merci, Oxford American Writer's Thesaurus tel que présenté par l'application Dictionary d'OS X !

• run
• execute
• go
  
  
  
  • Voir au dessus
  
  
• create (comme make )
• fabricate (trop long, trop facile à confondre avec fab )
• fab (c'est-à-dire que cette nouvelle bibliothèque est nommée différemment mais installe toujours un binaire fab ; si les deux sont présents sur le système, celui de Fabric a la priorité ? Cela semble être une idée stupide.)
• generate
• produce
• fashion (meh)
• build
• devise
• shape
• setup
• weave

Pas en pleine forme de remue-méninges aujourd'hui. Envie de moar.

@dstufft Loom est un nom correct, et CEO est un concept plutôt correct (pas un grand fan de la référence de la bande dessinée, ne serait-ce que parce qu'elle semble obscure, je n'avais jamais entendu parler du personnage ;)). Le problème principal est de trouver un bon nom binaire, j'ai l'impression qu'un verbe est à peu près indispensable pour que cela fonctionne bien. Je ne sais pas ce qui fonctionnerait pour l'un ou l'autre.

Patron : Exécute les choses.

participer. Un peu comme Make, mais pour Python.

Exécutif.

J'aime l'idée de l'orienter autour des tâches. Hmm..

@kennethreitz J'aime Boss, à part la confusion potentielle avec un certain natif du New Jersey (désolé, mais pas fan, mauvaise expérience de colocation à l'université)

Comme je l'ai dit à @dstufft , les noms binaires sont définitivement essentiels ici, donc si vous le pouvez, essayez de les garder également à l'esprit. Un bon nom de projet n'aide pas si le nom du projet en tant que fichier binaire semble un peu stupide ;)

La femme de ménage est intéressante. Effectue vos tâches pour vous. Similaire à "Fabriquer".

Le majordome aussi. On pourrait choisir au hasard un nom de majordome à consonance britannique.

maid clean , maid release , maid test . Je l'aime bien.

En plus d'empiéter sur ma masculinité (illimitée, naturellement), maid est plutôt bon, même s'il ne correspond pas au modèle verbal. (C'est-à-dire que c'est l'un des meilleurs noms binaires non verbaux.) (EDIT : et que font les majordomes ? Butle ?)

J'ai juste squatté le nom, juste au cas où. J'aime beaucoup jusqu'ici.

Boss comme nom de bibliothèque est déjà pris FWIW

Le mardi 21 février 2012 à 20h38, Jeff Forcier a écrit :

En plus d'empiéter sur ma masculinité (illimitée, naturellement), maid est plutôt bon, même s'il ne correspond pas au modèle verbal. (C'est-à-dire que c'est l'un des meilleurs noms binaires non verbaux.)

---

Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/fabric/fabric/issues/565#issuecomment -4095609

intern est aussi un choix incroyablement génial.

@dstufft C'est donc le cas, et je ne pouvais pas non plus penser à un bon nom binaire pour cela, boss docs ne correspond pas vraiment bien.

@kennethreitz a mentionné bake sur IRC, ce qui correspond au thème make/rake, et correspond également en quelque sorte à un verbe d'invocation (par exemple, $ bake docs , bien que thématiquement, c'est un peu décalé, ça donne l'impression ' d s'intégrer mieux dans Chef ou quelque chose.

MODIFIER : aussi deliver . Ma réaction initiale à celui-ci a été quelque peu positive ( $ deliver build $ deliver docs ) mais il n'y a pas de nom de projet _super_ pour l'accompagner qui ne soit un peu trop idiot, et c'est un peu long.

$ invoke taskname (noms de projets : invoker , invoked , ???)

Invoqué.

J'aime vraiment Invoked et invoke docs invoke tests invoke publish etc.

Le nom du projet pourrait également être "Invoke", le binaire et le projet ont-ils besoin de noms différents ?

Je pense que "invoked" a un peu plus de piquant que "invoke", mais l'un ou l'autre pourrait fonctionner.

Le nom n'a pas à différer, non, c'est juste que souvent cela a plus de sens.

J'ai eu une pensée en marchant vers le train (dans ledit train maintenant : P, allez-y pour connecter votre smartphone !), c'est que nous _pourrions_ éventuellement ignorer tout cela et simplement déplacer tout le côté fab + fabfile.py de choses à cette "nouvelle" bibliothèque (et appelez-la, disons, fabricator ).

En d'autres termes, en avoir un appelable pour la bibliothèque autonome et un autre pour la configuration utilisant SSH ne doit pas nécessairement se produire, et pourrait même être un inconvénient.

Avantages :

• Pas besoin d'un nouveau nom binaire
• Avoir deux noms binaires serait déroutant de toute façon
• Si la nouvelle bibliothèque _n'utilisait pas_ "fabfiles", nous aurions également deux types de "fichiers de tâches" différents, encore une fois confus/code supplémentaire/etc

Moins :

• Confusion potentielle entre les deux projets en raison de noms similaires
• Le nouveau projet devrait être plus extensible pour permettre à tous les Fabric-isms (par exemple, presque tous les indicateurs CLI, etc.) de continuer à fonctionner tels quels
  
  
  
  • C'est-à-dire pip install fabricator nous donne fab , qui aurait un petit ensemble de drapeaux
  
  
  • Ensuite, si vous pip install fabric , tout à coup le même fab doit afficher tous les indicateurs Fabric CLI supplémentaires, sinon d'autres choses aussi
  
  
  • OTOH, ce n'est pas comme autoriser le code "client" à étendre l'analyse CLI est une _mauvaise_ chose, c'est juste plus de travail qui doit être fait en amont.
  
  

Vous pouvez faire en sorte qu'un client en ligne de commande devienne extensible. Regardez comment nose permet aux points d'entrée du plugin d'être exprimés à partir de son outil de ligne de commande

Je pense que l'extensibilité supplémentaire serait une bonne chose, quelle que soit la manière dont cela se passe.

La confusion des noms serait un problème je pense.

C'est une chose personnelle mais j'aime mieux le look de invoke test invoke docs que fab test .

En ce qui concerne les différents binaires, je m'assurerais simplement que le binaire de base (invoke) est extensible pour permettre à toutes les choses de tissu de se produire, puis que fab appelle simplement le même point d'entrée que l'invocation (c'est-à-dire les binaires réels fab/invoke serait juste des appelants ultra minimalistes d'un main() (ou autre).

Je pense que si vous empruntez la route Invoke + Fabric qui pré-2.0 à la fois fabfiles et "Invokefiles"? serait pris en charge, puis avec la version 2.0, invoquez simplement les fichiers ?

Donc, essentiellement, je suis +1 pour le diviser en "task runner" et "remote/ssh stuff" distincts, en mettant des cales de compatibilité pour 1.x et en dépréciant des trucs pour 2.x. Je pense que cette scission améliorerait les deux bibliothèques, le gestionnaire de tâches prendrait en charge une extensibilité vraiment agréable (et probablement des tâches externes sur lesquelles on peut facilement compter, exécuter, etc.). Et le truc à distance/ssh gagnerait à avoir un ensemble de responsabilités plus petit lui permettant d'être plus concentré/

Mes centimes en tout cas.

Je devrais préciser que je ne déteste pas l'autre sens, je suis heureux que cette discussion ait lieu du tout :)

@dstufft Merci beaucoup pour les réflexions, je suis d'accord avec à peu près tout cela. Vous avez raison de dire que les binaires ne sont que des stubs, c'est ainsi que Fabric fonctionne maintenant, ma préoccupation concerne uniquement le comportement et la confusion des utilisateurs.

@dcolish Je ne voulais pas dire qu'il n'est pas possible de faire les extensions CLI, et le nez est certainement un bon art antérieur à examiner.

Si nous utilisons "invoke", peut-être que le nom du fichier pourrait être invocations(.py) ? Une touche du côté idiot / parc à thème, mais cela correspond grammaticalement, et invokefile.py me semble un peu gênant. Ou éventuellement suivre la voie de la convention Rake et utiliser simplement tasks(.py) .

En partie lié, je pense que nous devrions également nous concentrer sur l'aspect module/dossier à l'avenir. Comme il s'agit de Just Python, l'un ou l'autre serait toujours pris en charge, mais en termes de matériel didactique et de documentation, avoir invocations/__init__.py par défaut pourrait être une bonne chose à faire.

J'aime tasks.py . invocations.py est bizarre à taper.

Eh bien, ce n'est pas comme si vous deviez le taper très fréquemment, hein ? ;) Mais oui, tasks/ ou tasks.py est un peu plus évident globalement.

taskfile.py

vous invoke tâches (.py|/), le libellé est sympa de toute façon :)

Oui, la configuration "ce sont tasks que vous invoke " fonctionne très bien du point de vue de l'association des mots clés avec des descriptions en anglais de la façon dont cela fonctionne. C'est évident, sans fioritures, sans vanité, etc.

@kennethreitz Je n'ai jamais vraiment _été_ un grand fan de XYZFile en tant que convention de dénomination, et d'autant plus que ces jours-ci, il ne s'agit souvent _pas_ d'un seul fichier, je ne vois pas la nécessité de continuer la convention en dehors de Fab 1.x :)

J'aimerais vraiment que cela se produise. J'ai toujours considéré Fabric comme un moyen Pythonic générique de stocker des "tâches" pour un projet, qu'elles soient locales ou distantes, quelque chose de plus proche de Rake/Make. Cependant, en essayant d'introduire de nouvelles personnes, plusieurs personnes étaient confuses sur ce point de vue et ne le considéraient que comme un outil de déploiement.

J'appuierais l'aspect module/dossier, pour qu'il soit plus facile de créer des tâches génériques pouvant être ajoutées. Les nouvelles tâches de style ont définitivement contribué à cela.

@askedrelic Yup, avoir deux choses en une a toujours été un peu déroutant malheureusement.

Sans rapport : j'invoque @tswicegood sur ce fil puisque lui et moi discutions de la question il y a quelques semaines et je pense qu'il pourrait vouloir intervenir. Comme d'habitude, je me réserve le droit de ne pas être d'accord ;)

J'ai été convoqué ? :-)

J'aime l'idée de passer à tasks comme module plutôt qu'à fabfile . Plus logique et plus court. Pour ma part, je déteste avoir à installer la pile complète de dep juste pour pouvoir exécuter fab test à l'intérieur d'Armstrong, donc tout ce qui pourrait être fait pour extraire que je suis un gros plus.

En ce qui concerne le nommage, que diriez-vous de passer d'un exécutable externe installé à des personnes qui ajoutent ceci en bas :

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

Ensuite, vous utilisez simplement Python. Je suis d'accord avec un exécutable, mais je ne sais pas si c'est nécessaire.

FWIW, j'ai lancé un projet il y a quelques semaines pour gérer la création de packages appelé flunky . S'en tenir à ce thème associé, footman ou lacky sont tous deux disponibles (ce dernier a un conflit avec lackie -- un projet Ruby). Un autre serait vendredi, comme dans girl/man friday . Il passe le test GitHub/PyPI/Homebrew en ce sens qu'il n'y a rien de nommé. En fait, maintenant que j'y pense, ce serait mon premier choix.

Pari parallèle, je me demande combien de temps il faudrait jusqu'à ce que @niran soumette un PR mettant à jour le README pour inclure la chanson thème évidente, bien qu'horrible.

Je pense qu'avoir un "binaire" sur votre $PATH (surtout étant donné que ce n'est actuellement _pas_ un vrai binaire mais juste un stub créé par setuptools qui appelle (invoked|fabric).main() ) est le plus convivial , et je ne vois aucun avantage à déplacer le contenu de ce stub pour qu'il soit généré automatiquement dans le module de tâches (et en fait, j'y vois un certain nombre d'inconvénients.)

Et oui, tout l'intérêt de ceci est de se retrouver avec une bibliothèque qui vous permet d'obtenir les tâches difficiles sans avoir besoin de SSH/réseau/crypto deps :)

Je suis entièrement d'accord avec @bitprophet sur l'exécutable. Cela rend la course beaucoup plus facile. Si quelqu'un veut utiliser autre chose que invoke / fab sur son projet personnel, c'est juste un stub pour que vous puissiez facilement créer votre propre binaire (et il pourrait facilement vivre à finalname.__main__.main , auquel cas vous pourriez aussi juste python -m finalname si vous le vouliez aussi.

+1.

Juste lancer une idée là-bas, je pense que c'est plus pratique aussi. FWIW, je me suis inscrit vendredi sur PyPI si vous souhaitez l'utiliser.

@bitprophet Désolé, je pensais que vous saviez comment utiliser les points d'entrée. Je votais, à ma manière, pour faire une interface similaire à nose et garder le nom aussi fabuleux.

Les idées sont géniales, j'adore les idées :)

Vendredi est un peu trop mièvre, bien que j'aime la référence à la culture pop. Cette chanson est tellement géniale ! :visage de troll:

Je pense que pour l'instant j'utilise directement invoke comme nom de package/projet et nom binaire. Yoink ! Invoker ou Invoked étaient d'autres possibilités pour le premier (c'est-à-dire toujours avec un binaire invoke ) mais je ne pouvais penser à aucune bonne raison de ne pas suivre la voie directe.

Le principal inconvénient de ce nom est le caractère générique, mais c'est un problème avec tous les projets que j'ai repris ou créés, et dans ce cas, aucune des options plus spécifiques ne me convenait. /justification

@dcolish Reconnu, merci !

Je n'ai pas encore pris de décision finale, mais je pense qu'à ce stade, l'approche sensée est la suivante :

• Invoke est sa propre chose, sa propre nouvelle identité/"marque", utilise le binaire invoke , recherche le module tasks , etc.
  
  
  
  • C'est propre, simple conceptuellement pour les utilisateurs utilisant uniquement Invoke et non Fabric, supprime les bagages historiques, etc.
  
  
• Invoke expose tout code partagé que Fabric (ou d'autres outils) pourrait vouloir utiliser, en tant qu'API publiques
• Fabric continue d'utiliser fab et recherche un module fabfile , tout en ajoutant une dépendance au moment de l'installation sur Invoke, et utilise les API d'Invoke pour appeler ce code partagé
  
  
  
  • Cela signifie que l'installation de Fabric génère deux binaires, mais du point de vue des utilisateurs qui se concentrent sur Fabric, ils n'ont pas besoin de _savoir_ que invoke / tasks existent/sont des options, car elles Je ne les utiliserai jamais - fab est toujours un sur-ensemble de fonctionnalités.
  
  
  • Les utilisateurs qui souhaitent utiliser à la fois Invoke pour leur propre bien (par exemple, dans d'autres projets qui n'ont pas de Fabfiles) _and_ Fabric sont le point de friction, re : comment invoke et fabric sont liés les uns aux autres et se comportent . Ces gens pourraient avoir un certain intérêt à ce invoke et fab soient de simples alias l'un de l'autre (c'est-à-dire que l'installation de Fabric modifie le comportement invoke , comme le fonctionnement des plugins Nose).
  
  
  • Cependant, je pense qu'il est préférable que les deux se comportent différemment - fab _doit_ différencier _au moins_ dans le "quel nom de module de tâche dois-je rechercher?" sens, à quel point nous pouvons aussi bien avoir sa propre créature, et la relation entre Fabric et Invoke est uniquement dans la façon dont Fabric utilise la base de code d'Invoke.
  
  

EDIT : Je devrais jeter un œil à _comment_ cela fonctionnera, rapidement, avant de faire quoi que ce soit de définitif. Pratique vs théorie et tout ça. Peut se heurter à des angles auxquels je ne pense pas ici.

Invoke a maintenant une version bêta (après de nombreux travaux récents pour la construire). Déjà là:

• Espacement des noms meilleur, plus explicite mais toujours presque nul
• Analyseur d'indicateur CLI "réel", pas plus foo:bar,lol , y compris la traduction automatique de la fonction argspec en spécification CLI
• Tentative de conception de bits d'exécution de tâche extensibles/surmontables concernant la parallélisation
• Ce qui a été fait pour prendre en charge : les pré-tâches (indiquer les tâches à exécuter avant les autres tâches)
• Coureur de tâches local capable de capturer et d'imprimer run (bien que probablement non fonctionnel sous Windows)
• Peut-être oublier quelques autres morceaux?

Sprinter dessus et espérer commencer à prototyper comment Fab 2 se boulonnera dessus, cette semaine.

assurer la propreté
assurer la construction
"assurer" "état"

Quel est l'état du tissu 2 ? Y a-t-il une fourchette qui couvre cela? Je veux dire les choses que fabric2 devrait couvrir et qui ne sont pas invoquées.

@mvaled Il apparaîtra sous peu, a été dans une branche privée "propre" du dépôt de tissu.

Désolé si c'est hors sujet mais je dois en quelque sorte demander à nouveau:
Où puis-je trouver le tissu 2 ?
J'aime vraiment Invoke et cela ressemble à une énorme amélioration, mais que manque-t-il pour une version Invoke 1.0 ? (décrit comme la base du tissu 2)

Merci pour tout l'excellent travail sur l'invocation et le tissu !

@dmr Je suis en train de faire fonctionner un Fabric 2 au-dessus d'Invoke. Un tas de fonctionnalités à porter depuis Fabric 1 éclaireront les décisions de conception pour Invoke (pour les nouvelles fonctionnalités ou celles existantes - par exemple, la récente révision de la configuration en faisait partie), donc je ne veux pas étiqueter Invoke 1.0 tant qu'il n'a pas été " testé au combat" suffisamment.

Mon plan est d'avoir un alpha de Fabric 2 prêt pour le public par PyCon au plus tard (idéalement beaucoup plus tôt) et cela mènera à Fabric 2.0 + Invoke 1.0.

Merci pour la précision, où puis-je vous aider ?

J'y travaille dans une branche privée à court terme jusqu'à ce que j'obtienne quelque chose dont je suis satisfait et je l'annoncerai sur twitter/liste de diffusion/etc une fois que je serai prêt à recevoir des commentaires, alors restez à l'écoute.

J'ai commencé à passer à invoquer en combinaison avec des commandes shell et quelques Paramiko car fabric est le dernier paquet sans prise en charge de python3 dans mon projet

Une ETA pour Fabric 2.0 et Invoke 1.0 car Python 3.5 a été publiée hier et sera la valeur par défaut dans Ubuntu 16.04 LTS ?