Fabric: Divida las funciones que no dependen de ssh en lib separadas

:pastel:

Una herramienta totalmente nueva que encajaría bien en el caso de uso siempre es una opción, por supuesto.

Descripción actualizada un montón.

@kennethreitz : esto realmente sería una "cosa" nueva, simplemente basada en las necesidades/conjunto de características existentes de esa mitad de Fabric. La idea es que sea su propia entidad en relación con la instalación, el cronograma de desarrollo, etc., pero aún controlado por los desarrolladores/comunidad de Fabric.

Ideas:

• tony - como en Tony Masters, también conocido como The Taskmaster (cómics ~)
• CEO - Dirige las cosas, (o zar o algo similar en ese sentido)

Lo siento, apesto con los nombres :(

También cosas como "kirk" (como en el capitán kirk).

Traté de pensar en algo relacionado con fabric que tenga que ver con la ejecución de tareas, pero no puedo pensar en uno que se relacione con tareas + fabric.

Pero Loom tampoco es un mal nombre, no lo creo.

Lluvia de ideas sobre el nombre inicial.

Conceptos

• Correr/trotar/etc.
• Ejecución (de órdenes, personas quizás aunque eso sea un poco macabro, etc.)
• Tareas (como cosas por hacer, diligencias, etc.)
• Tal vez algunos de los nombres rechazados o similares del n. ° 461, en la medida en que la idea de tejer o armar cosas con tela también se aplica a las tareas.

Nombres no tomados en PyPI

• runner
• executor
• go
  
  
  
  • Confusión con el lenguaje de programación y/o el juego de mesa, especialmente si el primero tiene un binario llamado específicamente go
  
  
  • Para bien o para mal, tiene muchos nombres de tareas potencialmente tontos como away o fuck_yourself o bother_somebody_else
  
  
• weaver

nombres binarios

¡Gracias, Oxford American Writer's Thesaurus presentado por la aplicación Dictionary de OS X!

• run
• execute
• go
  
  
  
  • Véase más arriba
  
  
• create (como make )
• fabricate (demasiado largo, demasiado fácil de confundir con fab )
• fab (es decir, tener esta nueva biblioteca con un nombre diferente pero aún instalando un binario fab ; si ambos están presentes en el sistema, ¿el de Fabric tiene prioridad? Parece una idea tonta).
• generate
• produce
• fashion (bueno)
• build
• devise
• shape
• setup
• weave

No en la mejor forma de lluvia de ideas hoy. Quiere moar.

@dstufft Loom es un buen nombre, y CEO es un concepto mayormente aceptable (no soy un gran admirador de la referencia del cómic, aunque solo sea porque parece oscuro, nunca había oído hablar del personaje;)). El problema principal es encontrar un buen nombre binario, siento que un verbo es casi imprescindible para que funcione bien. No estoy seguro de qué funcionaría para cualquiera de esos.

Jefe: Dirige las cosas.

participar. Algo así como Make, pero para Python.

Ejecutivo.

Me gusta la idea de que se oriente en torno a las tareas. Mmm..

@kennethreitz Me gusta Boss, aparte de la posible confusión con cierto nativo de Nueva Jersey (lo siento, pero no soy un fanático, mala experiencia de compañero de cuarto en la universidad)

Como le dije a @dstufft , los nombres binarios son definitivamente clave aquí, así que si puede, intente tenerlos en cuenta también. Un gran nombre de proyecto no ayuda si el nombre del proyecto como binario suena un poco tonto;)

La criada es interesante. Realiza sus tareas por usted. Similar a "Hacer".

Mayordomo también. Podríamos elegir un nombre de mayordomo al azar que suene británico.

maid clean , maid release , maid test . Me gusta.

Además de incidir en mi masculinidad (sin límites, naturalmente), maid es bastante bueno, aunque no se ajusta al patrón verbal. (Es decir, es uno de los mejores nombres binarios no verbales). (EDITAR: ¿y qué hacen los mayordomos? ¿Butle?)

Acabo de poner en cuclillas el nombre, por si acaso. Hasta ahora me gusta un montón.

Boss como nombre de biblioteca ya está tomado FWIW

El martes 21 de febrero de 2012 a las 20:38, Jeff Forcier escribió:

Además de incidir en mi masculinidad (sin límites, naturalmente), maid es bastante bueno, aunque no se ajusta al patrón verbal. (Es decir, es uno de los mejores nombres binarios no verbales).

---

Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/fabric/fabric/issues/565#issuecomment -4095609

intern también es una opción increíblemente increíble.

@dstufft Así es, y tampoco pude pensar en un buen nombre binario para eso, boss docs realmente no encaja bien.

@kennethreitz mencionó bake en IRC, que encaja con el tema de hacer/rake, y también encaja como un verbo de invocación (por ejemplo $ bake docs , aunque temáticamente está un poco fuera de lugar, se siente así) encajaría mejor en Chef o algo así.

EDITAR: también deliver . Mi reacción inicial a este fue algo positiva ( $ deliver build $ deliver docs ) pero no hay un nombre de proyecto _gran_ que lo acompañe que no sea demasiado tonto, y es un poco largo.

$ invoke taskname (nombres de proyecto: invoker , invoked , ???)

invocado.

Me gusta mucho Invoked y invoke docs invoke tests invoke publish etc.

El nombre del proyecto también podría ser "Invocar", ¿el binario y el proyecto necesitan nombres diferentes?

Creo que 'invocado' tiene un poco más de dinamismo que 'invocar', pero cualquiera podría funcionar.

El nombre no tiene por qué ser diferente, no, es que muchas veces tiene más sentido.

Se me ocurrió una idea mientras caminaba hacia el tren (en dicho tren ahora: ¡Vamos a conectarnos con el teléfono inteligente!) y es que _podríamos_ omitir todo esto y simplemente mover todo el lado fab + fabfile.py de cosas a esta "nueva" biblioteca (y llámela, digamos, fabricator ).

En otras palabras, tener uno que se pueda llamar para la biblioteca independiente y otro diferente para la configuración que usa SSH no necesariamente tiene que suceder, e incluso podría ser perjudicial.

Ventajas:

• No es necesario un nuevo nombre binario
• Tener dos nombres binarios sería confuso de todos modos
• Si la nueva lib _no_ usara "fabfiles", también tendríamos dos tipos diferentes de "archivo de tareas", nuevamente confuso/código adicional/etc.

Contras:

• Posible confusión entre los dos proyectos debido a nombres similares
• El nuevo proyecto tendría que ser más extensible para permitir que todos los Fabric-ismos (p. ej., casi todas las banderas de la CLI, etc.) continúen funcionando tal como están.
  
  
  
  • Es decir pip install fabricator nos da fab , que tendría un pequeño conjunto de banderas
  
  
  • Luego, si pip install fabric , de repente el mismo fab tiene que exhibir todas las banderas adicionales de Fabric CLI, si no otras cosas también
  
  
  • OTOH no es como permitir que el código "cliente" amplíe el análisis de CLI es algo _malo_, es solo más trabajo que debe hacerse por adelantado.
  
  

Puede hacer que un cliente de línea de comandos se vuelva extensible. Mire cómo nose permite que los puntos de entrada del complemento se expresen desde su herramienta de línea de comandos

Creo que la extensibilidad adicional sería algo bueno, independientemente de la dirección que tome.

Creo que la confusión de nombres sería un problema.

Esto es algo personal, pero me gusta más el aspecto de invoke test invoke docs que el de fab test .

En lo que respecta a los diferentes binarios, solo me aseguraría de que el binario central (invocar) sea extensible para permitir que sucedan todas las cosas de la estructura, y luego hacer que fab simplemente llame al mismo punto de entrada que invocar (es decir, los binarios reales de fab/invoke serían personas que llaman ultra minimalistas de un main() (o lo que sea).

¿Creo que si vas a la ruta de invocación + tela que pre 2.0 tanto fabfiles como "Invokefiles"? sería compatible, y luego con 2.0 solo invocar archivos?

Entonces, esencialmente, soy +1 por dividirlo en distintos "ejecutores de tareas" y "cosas remotas/ssh", poner compatibilidades para 1.x y desaprobar cosas para 2.x. Creo que esta división mejoraría ambas bibliotecas, el ejecutor de tareas admitiría una capacidad de extensión realmente agradable (y probablemente tareas externas de las que se puede depender fácilmente, ejecutar, etc.). Y las cosas remotas/ssh se beneficiarían de tener un conjunto más pequeño de responsabilidades que le permitan estar más enfocado/

Mis centavos de todos modos.

Debo aclarar que no odio lo contrario, estoy feliz de que esta discusión esté sucediendo en absoluto :)

@dstufft Muchas gracias por los pensamientos, estoy de acuerdo con casi todo eso. Tienes razón acerca de que los archivos binarios solo son stubs, así es como funciona Fabric ahora, mi preocupación es únicamente sobre el comportamiento y la confusión del usuario.

@dcolish No quería dar a entender que no es posible hacer las extensiones de la CLI, y nose es definitivamente un buen estado de la técnica para examinar.

Si vamos con "invocar", ¿tal vez el nombre del archivo podría ser invocations(.py) ? Un toque en el lado tonto/parque temático, pero encaja gramaticalmente, y invokefile.py me parece un poco incómodo. O posiblemente siga la ruta de la convención Rake y simplemente use tasks(.py) .

Parcialmente relacionado, creo que definitivamente también deberíamos mejorar/centrarnos en el aspecto del módulo/carpeta en el futuro. Dado que es Just Python, cualquiera de los dos seguiría siendo compatible, pero en términos de material de tutorial y documentos, tener invocations/__init__.py como valor predeterminado podría ser una buena opción.

Me gusta tasks.py . invocations.py es raro de escribir.

Bueno, no es como si tuvieras que escribirlo con mucha frecuencia, ¿eh? ;) Pero sí, tasks/ o tasks.py es un poco más obvio a nivel mundial.

taskfile.py

usted invoke tareas (.py|/), la redacción es agradable de todos modos :)

Sí, la configuración "estos son tasks que usted invoke " funciona muy bien desde la perspectiva de vincular las palabras clave con descripciones en inglés de cómo funciona. Es obvio, sin florituras, sin vanidad, etc.

@kennethreitz Realmente nunca he _sido_ un gran admirador de XYZFile como convención de nomenclatura, y especialmente dado que en estos días con frecuencia _no_ es un solo archivo, no veo la necesidad de continuar con la convención fuera de Fab 1.x :)

Me encantaría ver que esto suceda. Siempre he visto a Fabric como una forma Pythonic genérica de almacenar "tareas" para un proyecto, ya sean locales o remotos, algo más cercano a Rake/Make. Sin embargo, al tratar de presentarles a nuevas personas, varias personas se confundieron con este punto de vista y lo vieron solo como una herramienta de implementación.

Secundaría el aspecto del módulo/carpeta, para que sea más fácil hacer tareas genéricas que se puedan incorporar. Las nuevas tareas de estilo definitivamente fueron un buen camino hacia eso.

@askedrelic Sí, tener dos cosas en una siempre ha sido un poco confuso, desafortunadamente.

Sin relación: convoco a @tswicegood a este hilo ya que él y yo estuvimos discutiendo el tema hace unas semanas y me imagino que tal vez quiera opinar. Como de costumbre, me reservo el derecho a estar en desacuerdo;)

fui convocado? :-)

Me gusta la idea de pasar a tasks como módulo en lugar de fabfile . Tiene más sentido y es más corto. Yo, por mi parte, odio tener que instalar la pila de distribución completa solo para poder ejecutar fab test dentro de Armstrong, así que cualquier cosa que se pueda hacer para extraer que soy una gran ventaja.

En cuanto a los nombres, ¿qué tal pasar de tener un ejecutable externo instalado a que la gente agregue esto al final?

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

Entonces solo usas Python. Estoy bien con un ejecutable, pero no sé si es necesario.

FWIW, comencé un proyecto hace unas semanas para manejar la creación de paquetes llamado flunky . Siguiendo con ese tema asistente, footman o lacky están disponibles (este último tiene un conflicto con lackie , un proyecto de Ruby). Otro sería el viernes, como en chica/hombre viernes . Pasa la prueba de GitHub/PyPI/Homebrew en el sentido de que no hay nada llamado así. En realidad, ahora que lo pienso, esa sería mi primera opción.

Apuesta adicional, me pregunto cuánto tiempo pasará hasta que @niran envíe un PR actualizando el README para incluir el tema musical obvio, aunque horrible.

Creo que tener un "binario" en su $PATH (especialmente dado que actualmente _no_ es un binario real, sino solo un código auxiliar creado con herramientas de configuración que llama a (invoked|fabric).main() ) es lo más fácil de usar , y no veo ningún beneficio en mover el contenido de ese código auxiliar para que se genere automáticamente dentro del módulo de tareas (y, de hecho, veo una serie de desventajas).

Y sí, el objetivo de esto es terminar con una librería que te permita realizar tareas sin necesidad de SSH/network/crypto deps :)

Estoy completamente de acuerdo con @bitprophet en el ejecutable. Hace que sea mucho más fácil de ejecutar. Si alguien quiere usar algo que no sea invoke / fab en su proyecto personal, es solo un código auxiliar para que pueda crear fácilmente su propio binario (y podría vivir fácilmente en finalname.__main__.main , en cuyo caso también podría simplemente python -m finalname si quisiera también.

+1.

Solo lanzando una idea, creo que también es más conveniente. FWIW, me registré el viernes en PyPI si quieres usarlo.

@bitprophet Lo siento, pensé que sabías cómo usar los puntos de entrada. Estaba votando, a mi manera, por hacer una interfaz similar a nose y mantener el nombre como fabuloso.

Las ideas son geniales, me encantan las ideas :)

El viernes es un poco cursi, aunque me gusta la referencia a la cultura pop. ¡Esa canción es tan genial! :Cara de burla:

Creo que por ahora voy directamente con invoke como el nombre del paquete/proyecto y binario. Yoink! Invoker o Invoked eran otras posibilidades para el primero (es decir, todavía con un binario invoke ), pero no podía pensar en ninguna buena razón para no seguir la ruta directa.

El principal inconveniente de este nombre es el carácter genérico, pero ese es un problema con todos los proyectos que he asumido o creado, y en este caso, ninguna de las opciones más específicas me pareció adecuada. /justificación

@dcolish Reconocido, gracias!

Todavía no he tomado una decisión final, pero creo que en este punto el enfoque sensato es:

• Invocar es algo propio, propia nueva identidad/"marca", usa el binario invoke , busca el módulo tasks , etc.
  
  
  
  • Esto es conceptualmente limpio y sencillo para los usuarios que solo usan Invoke y no Fabric, elimina el equipaje histórico, etc.
  
  
• Invoke expone cualquier código compartido que Fabric (u otras herramientas) puedan querer usar, como API públicas
• Fabric continúa usando fab y busca un módulo fabfile , mientras agrega una dependencia de tiempo de instalación en Invoke, y usa las API de Invoke para llamar a ese código compartido
  
  
  
  • Esto significa que la instalación de Fabric da como resultado dos binarios, pero desde la perspectiva de los usuarios que se centran en Fabric, no necesitan _saber_ que invoke / tasks existen/son opciones, porque Nunca los usaría: fab sigue siendo un superconjunto de funciones.
  
  
  • Los usuarios que quieren usar Invoke por su propio bien (por ejemplo, en otros proyectos que no tienen Fabfiles) _y_ Fabric son el punto de fricción, re: cómo invoke y fabric se relacionan entre sí y se comportan . Estas personas podrían tener algún interés en que invoke y fab sean simples alias entre sí (es decir, que la instalación de Fabric mute cómo se comporta invoke , como cómo funcionan los complementos de Nose).
  
  
  • Sin embargo, creo que es mejor que los dos se comporten de manera diferente -- fab _debe_ diferenciar _al menos_ en "¿qué nombre de módulo de tareas busco?" sentido, en cuyo punto podemos hacer que sea su propia criatura, y la relación entre Fabric e Invoke es solo en cómo Fabric usa la base de código de Invoke.
  
  

EDITAR: Debería echar un vistazo a _cómo_ funcionará esto, rápidamente, antes de hacer nada definitivo. Práctica vs teoría y todo eso. Puede encontrarse con ángulos en los que no estoy pensando aquí.

Invoke tiene una versión beta ahora (después de mucho trabajo reciente para desarrollarlo). Ya estoy en eso:

• Espacio de nombres mejor, más explícito pero aún casi cero repetitivo
• Analizador de bandera CLI "real", no más foo:bar,lol , incluida la traducción automática de la función argspec a la especificación CLI
• Se intentó diseñar bits de ejecución de tareas para que fueran extensibles/anulables en relación con: paralelización
• Lo que se hizo para respaldar: tareas previas (indicar las tareas que se ejecutarán antes que otras tareas)
• ejecutor de tareas local con capacidad para capturar e imprimir run (aunque probablemente no funcione en Windows)
• ¿Podría estar olvidando otro par de bits?

Corriendo en él y con la esperanza de comenzar a crear prototipos de cómo Fab 2 se acoplará a él esta semana.

asegurar limpio
asegurar construido
"garantizar" "estado"

¿Cuál es el estado de la tela 2? ¿Hay un tenedor por ahí que esté cubriendo esto? Me refiero a las cosas que fabric2 debería cubrir que no se invocan.

@mvaled Aparecerá en breve, ha estado en una rama privada 'limpia' del repositorio de tela.

Lo siento si esto está fuera de tema, pero tengo que preguntar de nuevo:
¿Dónde puedo encontrar la tela 2?
Realmente me gusta invocar y se siente como una gran mejora, pero ¿qué falta para una versión de invocar 1.0? (descrito como base para el tejido 2)

¡Gracias por todo el gran trabajo en Invocate y Fabric!

@dmr Estoy en medio de hacer funcionar un Fabric 2 sobre Invoke. Un montón de funciones que se transferirán desde Fabric 1 informarán las decisiones de diseño para Invoke (para funciones nuevas o existentes, por ejemplo, la revisión de configuración reciente fue una de estas), por lo que no quiero etiquetar Invoke 1.0 hasta que haya sido " probado en batalla" suficientemente.

Mi plan es tener una alfa de Fabric 2 lista para el público por PyCon a más tardar (idealmente mucho antes) y eso conducirá a Fabric 2.0 + Invoke 1.0.

Gracias por la aclaración, ¿dónde puedo ayudar?

Estoy trabajando en ello en una sucursal privada a corto plazo hasta que obtenga algo que me satisfaga y lo anunciaré en twitter/lista de correo/etc una vez que esté listo para recibir comentarios, así que por favor estén atentos.

Empecé a cambiar para invocar en combinación con comandos de shell y algo de Paramiko porque fabric es el último paquete sin compatibilidad con python3 en mi proyecto.

¿Alguna ETA para Fabric 2.0 e Invoke 1.0 como Python 3.5 se lanzó ayer y será la predeterminada en Ubuntu 16.04 LTS?