Fabric: Divida recursos não dependentes de ssh em lib separada

:bolo:

Uma ferramenta totalmente nova que se encaixaria bem no caso de uso também é sempre uma opção, é claro.

Descrição atualizada um monte.

@kennethreitz : isso realmente seria uma nova "coisa", apenas com base nas necessidades/conjunto de recursos existentes dessa metade do Fabric. A ideia é que seja uma entidade própria em relação a: instalação, cronograma de desenvolvimento etc, mas ainda controlada pelos desenvolvedores/comunidade do Fabric.

Ideias:

• tony - como em Tony Masters aka The Taskmaster (quadrinhos~)
• CEO - Executa as coisas (ou czar ou algo semelhante nesse sentido)

Desculpe eu sou péssimo em nomes :(

Também coisas como "kirk" (como no capitão Kirk).

Tentei pensar em algo relacionado ao tecido que tenha a ver com a execução de tarefas, mas não consigo pensar em um que se relacione com tarefas + tecido.

Mas Loom também não é um nome ruim, eu não acho.

Brainstorm de nome inicial.

Conceitos

• Correr/correr/etc
• Execução (de ordens, pessoas talvez, embora seja um pouco macabro, etc)
• Tarefas (como em coisas a fazer, recados, etc.)
• Talvez alguns dos nomes rejeitados ou semelhantes do #461, na medida em que a ideia de tecer ou juntar coisas de tecido também se aplica a tarefas

Nomes não usados ​​no PyPI

• runner
• executor
• go
  
  
  
  • Confusão com a linguagem de programação e/ou jogo de tabuleiro, especialmente se o primeiro tiver um binário chamado especificamente go
  
  
  • Para melhor ou pior, tem muitos nomes de tarefas bobas em potencial, como away ou fuck_yourself ou bother_somebody_else
  
  
• weaver

Nomes binários

Obrigado, Thesaurus do Oxford American Writer conforme apresentado pelo aplicativo Dicionário do OS X!

• run
• execute
• go
  
  
  
  • Veja acima
  
  
• create (como make )
• fabricate (muito longo, muito facilmente confundido com fab )
• fab (ou seja, tem essa nova lib nomeada de forma diferente, mas ainda instalando um binário fab ; se ambos estiverem presentes no sistema, o Fabric tem precedência? Parece uma ideia idiota.)
• generate
• produce
• fashion (meh)
• build
• devise
• shape
• setup
• weave

Não na melhor forma de brainstorming hoje. Quer mourão.

@dstufft Loom é um nome OK, e CEO é um conceito basicamente ok (não sou um grande fã da referência em quadrinhos, mesmo porque parece obscuro, nunca ouvi falar do personagem;)). O principal problema é encontrar um bom nome binário, sinto que um verbo é praticamente obrigatório para que funcione bem. Não tenho certeza do que funcionaria para qualquer um desses.

Chefe: Executa as coisas.

participar. Meio como Make, mas para Python.

Executivo.

Eu gosto da ideia de orientar em torno de tarefas. Hmm..

@kennethreitz Eu gosto do Boss, além da possível confusão com um certo nativo de Nova Jersey (desculpe, mas não sou fã, má experiência de colega de quarto na faculdade)

Como eu disse para @dstufft , os nomes binários são definitivamente a chave aqui, então, se você puder, tente mantê-los em mente também. Um ótimo nome de projeto não ajuda se o nome-do-projeto-como-binário parecer meio idiota ;)

A empregada é interessante. Executa suas tarefas para você. Semelhante a "Fazer".

Mordomo também. Poderíamos escolher um nome aleatório de mordomo que soasse britânico.

maid clean , maid release , maid test . Eu gosto disso.

Além de afetar minha masculinidade (sem limites, naturalmente), maid é muito bom, mesmo que não se encaixe no padrão verbal. (Ie é um dos melhores nomes binários não verbais.) (EDIT: e o que os mordomos _do_? Butle?)

Eu apenas agachei o nome, apenas no caso. Eu gosto muito até agora.

Boss como um nome de biblioteca já foi usado FWIW

Em terça-feira, 21 de fevereiro de 2012 às 20h38, Jeff Forcier escreveu:

Além de afetar minha masculinidade (sem limites, naturalmente), maid é muito bom, mesmo que não se encaixe no padrão verbal. (Ou seja, é um dos melhores nomes binários não verbais.)

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/fabric/fabric/issues/565#issuecomment -4095609

intern também é uma escolha incrivelmente incrível.

@dstufft Então é, e eu também não consegui pensar em um bom nome binário para isso, boss docs realmente não se encaixa bem.

@kennethreitz mencionou bake no IRC, que se encaixa no tema make/rake, e também se encaixa como um verbo de invocação (por exemplo $ bake docs , embora tematicamente seja um pouco errado, parece' d encaixar melhor em Chef ou algo assim.

EDIT: também deliver . Minha reação inicial a este foi um pouco positiva ( $ deliver build $ deliver docs ), mas não há um _grande_ nome de projeto para acompanhá-lo que não seja um pouco bobo, e é um pouco longo.

$ invoke taskname (nomes dos projetos: invoker , invoked , ???)

Invocado.

Eu gosto muito de Invoked e invoke docs invoke tests invoke publish etc.

O nome do projeto também pode ser "Invoke", o binário e o projeto precisam de nomes diferentes?

Eu acho que 'invoked' tem um pouco mais de toque especial do que 'invoke', mas qualquer um deles pode funcionar.

O nome não precisa ser diferente, não, é só que muitas vezes faz mais sentido.

Eu tive um pensamento enquanto caminhava para o trem (no trem dito agora: P vá para o tethering do smartphone!), que é que nós _poderíamos_ possivelmente pular tudo isso e simplesmente mover todo o lado fab + fabfile.py de coisas para esta "nova" biblioteca (e chame-a, digamos, fabricator ).

Em outras palavras, ter um callable para a biblioteca autônoma e um diferente para a configuração que usa SSH não precisa necessariamente acontecer e pode até ser um prejuízo.

Vantagens:

• Não há necessidade de um novo nome binário
• Ter dois nomes binários seria confuso de qualquer maneira
• Se a nova lib _não_ usar "fabfiles", teríamos dois tipos diferentes de "arquivo de tarefa" também, novamente confuso/código extra/etc

Desvantagens:

• Potencial confusão entre os dois projetos devido a nomes semelhantes
• O novo projeto teria que ser extra extensível para permitir que todos os Fabric-isms (por exemplo, quase todos os sinalizadores CLI, etc.)
  
  
  
  • Ou seja pip install fabricator nos dá fab , o que teria um pequeno conjunto de sinalizadores
  
  
  • Então, se você pip install fabric , de repente o mesmo fab tem que exibir todos os sinalizadores adicionais do Fabric CLI, se não outras coisas também
  
  
  • OTOH, não é como permitir que o código "cliente" estenda a análise da CLI é uma coisa _ruim_, é apenas mais trabalho que precisa ser feito antecipadamente.
  
  

Você pode fazer com que um cliente de linha de comando se torne extensível. Veja como o nose permite que os pontos de entrada do plugin sejam expressos a partir de sua ferramenta de linha de comando

Eu acho que a extensibilidade extra seria uma coisa boa, independentemente de como ela for.

A confusão de nomes seria um problema, eu acho.

Isso é uma coisa pessoal, mas eu gosto da aparência de invoke test invoke docs melhor do que fab test .

No que diz respeito aos diferentes binários, eu apenas me certificaria de que o binário principal (invoke) seja extensível para permitir que todas as coisas da malha aconteçam e, em seguida, fab apenas chame o mesmo ponto de entrada que invocar (ou seja, os binários reais fab/invoke seriam apenas chamadores ultra minimalistas de main() (ou qualquer outra coisa).

Eu acho que se você seguir a rota de invocar + tecido que pré 2.0 tanto fabfiles quanto "Invokefiles"? seria suportado e, em seguida, com 2.0 apenas invocar arquivos?

Então, essencialmente, eu sou +1 por dividi-lo em "executor de tarefas" distinto e "coisas remotas/ssh", colocando shims compatíveis para 1.x e depreciando coisas para 2.x. Essa divisão eu acho que tornaria as duas libs melhores, o executor de tarefas suportaria uma extensabilidade muito boa (e provavelmente tarefas externas que podem ser facilmente dependentes, executadas etc). E o material remoto/ssh se beneficiaria de ter um conjunto menor de responsabilidades, permitindo que ele fosse mais focado/

Meus centavos de qualquer maneira.

Devo esclarecer que não odeio o outro lado, estou feliz que essa discussão esteja acontecendo :)

@dstufft Muito obrigado pelos pensamentos, concordo com praticamente tudo isso. Você está certo sobre os binários serem apenas stubs, é assim que o Fabric funciona agora, minha preocupação é apenas sobre comportamento e confusão do usuário.

@dcolish Eu não queria sugerir que não é possível fazer as extensões CLI, e o nariz é definitivamente uma boa arte prévia para examinar.

Se formos com "invoke", talvez o nome do arquivo possa ser invocations(.py) ? Um toque no lado bobo/parque temático, mas se encaixa gramaticalmente, e invokefile.py parece um pouco estranho para mim. Ou, possivelmente, siga a rota da convenção Rake e use tasks(.py) .

Parcialmente relacionado, acho que também devemos definitivamente aumentar/focar no aspecto do módulo/pasta daqui para frente. Como é apenas Python, qualquer um deles ainda seria suportado, mas em termos de material de tutorial e documentos, ter invocations/__init__.py como padrão pode ser uma boa coisa a fazer.

Eu gosto de tasks.py . invocations.py é estranho digitar.

Bem, não é como se você tivesse que digitar com muita frequência, hein? ;) Mas sim, tasks/ ou tasks.py é um pouco mais óbvio globalmente.

taskfile.py

você invoke tasks(.py|/), o texto é bom de qualquer maneira :)

Sim, a configuração "estes são tasks que você invoke " funciona muito bem na perspectiva de vincular as palavras-chave às descrições em inglês de como funciona. É óbvio, sem frescuras, sem vaidade, etc.

@kennethreitz Eu nunca fui realmente um grande fã do XYZFile como uma convenção de nomenclatura, e especialmente porque hoje em dia é frequentemente _não_ um único arquivo, não vejo necessidade de continuar a convenção fora do Fab 1.x :)

Eu adoraria ver isso acontecer. Eu sempre vi o Fabric como uma maneira Pythonic genérica de armazenar "tarefas" para um projeto, sejam elas locais ou remotas, algo mais próximo de Rake/Make. No entanto, ao tentar apresentar novas pessoas, várias pessoas ficaram confusas sobre esse ponto de vista e o viram apenas como uma ferramenta de implantação.

Eu apoiaria o aspecto do módulo/pasta, para que seja mais fácil tornar as tarefas genéricas que são drop-in. Tarefas de novo estilo definitivamente foram um bom caminho para isso.

@askedrelic Sim, ter duas coisas em uma sempre foi um pouco confuso, infelizmente.

Não relacionado: Convoco @tswicegood para este tópico desde que ele e eu estávamos discutindo o assunto há algumas semanas e acho que ele pode querer pesar. Como de costume, me reservo o direito de discordar;)

fui convocado? :-)

Eu gosto da ideia de passar para tasks como o módulo em vez de fabfile . Faz mais sentido e é mais curto. Eu, por exemplo, odeio ter que instalar o dep stack completo apenas para poder executar fab test dentro do Armstrong, então qualquer coisa que possa ser feita para extrair isso eu sou um grande plus.

No que diz respeito à nomenclatura, que tal mudar de ter um executável externo instalado para as pessoas adicionarem isso ao fundo:

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

Então você só usa Python. Estou bem com um executável, só não sei se é necessário.

FWIW, eu comecei um projeto algumas semanas atrás para lidar com a criação de pacotes chamado flunky . Mantendo esse tema de atendimento, footman ou lacky estão disponíveis (o último tem um conflito com lackie -- um projeto Ruby). Outra seria sexta-feira, como na sexta- feira menina/homem . Ele passa no teste GitHub/PyPI/Homebrew em que não há nada chamado isso. Na verdade, agora que penso nisso, essa seria minha primeira escolha.

Aposta paralela, eu me pergunto quanto tempo levaria até @niran enviar um PR atualizando o README para incluir a música-tema óbvia, embora horrível.

Eu acho que ter um "binário" no seu $PATH (especialmente dado que atualmente _não_ é um binário real, mas apenas um stub criado por setuptools que chama (invoked|fabric).main() ) é o mais amigável , e não vejo nenhum benefício em mover o conteúdo desse stub para ser gerado automaticamente dentro do módulo de tarefas (e, de fato, vejo várias desvantagens nisso.)

E sim, todo o objetivo disso é acabar com uma lib que permite obter as coisas complicadas sem precisar de nenhum SSH/network/crypto deps :)

Eu concordo completamente com @bitprophet no executável. Isso facilita muito a execução. Se alguém quiser usar algo diferente de invoke / fab em seu projeto pessoal, é apenas um stub para que você possa criar facilmente seu próprio binário (e pode facilmente viver em finalname.__main__.main , caso em que você também pode apenas python -m finalname se quiser também.

+1.

Só jogando uma ideia por aí, acho mais conveniente também. FWIW, eu registrei sexta-feira no PyPI se você quiser usá-lo.

@bitprophet Desculpe, imaginei que você soubesse como usar pontos de entrada. Eu estava votando, do meu jeito, para fazer um frontend parecido com o nose e manter o nome fabuloso.

As ideias são ótimas, adoro ideias :)

Sexta-feira é um pouco fofa demais, embora eu goste da referência à cultura pop. Essa música é tão grande! :cara de gozo:

Eu acho que por enquanto estou indo direto para invoke como o nome do pacote/projeto e do binário. Ei! Invoker ou Invoked eram outras possibilidades para o primeiro (ou seja, ainda com um binário invoke ), mas não consegui pensar em nenhuma boa razão para não seguir o caminho direto.

A principal desvantagem desse nome é o caráter genérico, mas isso é um problema com todos os projetos que já assumi ou criei e, neste caso, nenhuma das opções mais específicas me pareceu correta. /justificação

@dcolish Reconhecido, obrigado!

Ainda não tomei uma decisão final, mas acho que neste momento a abordagem sensata é:

• Invoke é algo próprio, possui uma nova identidade/"marca", usa invoke binário, procura o módulo tasks , etc.
  
  
  
  • Isso é limpo, conceitualmente direto para usuários que usam apenas o Invoke e não o Fabric, remove a bagagem histórica etc.
  
  
• Invoke expõe qualquer código compartilhado que o Fabric (ou outras ferramentas) queira usar, como APIs públicas
• O Fabric continua a usar fab e procura um módulo fabfile , enquanto adiciona uma dependência de tempo de instalação no Invoke e usa as APIs do Invoke para chamar esse código compartilhado
  
  
  
  • Isso significa que a instalação do Fabric resulta em dois binários, mas da perspectiva dos usuários com foco no Fabric, eles não precisam _saber_ que invoke / tasks existem/são opções, porque eles d nunca usá-los -- fab ainda é um superconjunto de funcionalidades.
  
  
  • Usuários que desejam usar o Invoke por si só (por exemplo, em outros projetos que não têm Fabfiles) _and_ Fabric são o ponto de discórdia, re: como invoke e fabric se relacionam e se comportam . Essas pessoas podem ter algum interesse em invoke e fab serem simples aliases um do outro (ou seja, fazer a instalação do Fabric mudar como invoke se comporta, como os plugins do Nose funcionam).
  
  
  • No entanto, acho que é melhor fazer com que os dois se comportem de maneira diferente - fab _deve_ diferenciar _pelo menos_ no "qual nome do módulo de tarefa eu procuro?" sentido, em que ponto podemos muito bem tê-lo como sua própria criatura, e a relação entre Fabric e Invoke é apenas em como o Fabric usa a base de código do Invoke.
  
  

EDIT: Eu deveria dar uma olhada em _como_ isso funcionará, rapidamente, antes de fazer qualquer coisa final. Prática x teoria e tudo mais. Pode entrar em ângulos que não estou pensando aqui.

O Invoke tem uma versão beta agora (depois de muito trabalho recente para criá-lo). Ja entrou:

• Namespaces melhores, mais explícitos, mas ainda quase zero
• Analisador de sinalizador CLI "real", não mais foo:bar,lol , incluindo tradução automática da função argspec para especificação CLI
• Tentativa de projetar bits de execução de tarefas para serem extensíveis/substituíveis re: paralelização
• O que foi feito para dar suporte: pré-tarefas (indicar tarefas a serem executadas antes de outras tarefas)
• executor de tarefas local capaz de capturar e imprimir run (embora provavelmente não seja funcional no Windows)
• Pode estar esquecendo mais alguns bits?

Correndo nele e esperando começar a prototipar como o Fab 2 se encaixará nele, esta semana.

garantir limpo
garantir construído
"garantir" "estado"

Qual é o status do tecido 2? Existe um garfo por aí que está cobrindo isso? Quero dizer, o material que o fabric2 deve cobrir que não é invocado.

@mvaled Ele aparecerá em breve, esteve em um ramo 'limpo' privado do repositório de tecidos.

Desculpe se isso estiver fora do tópico, mas eu meio que tenho que perguntar novamente:
Onde posso encontrar o tecido 2?
Eu realmente gosto de invocar e parece uma grande melhoria, mas o que está faltando para uma versão de invocar 1.0? (descrito como base para o tecido 2)

Obrigado por todo o grande trabalho em invocar e tecido!

@dmr Estou no meio de um Fabric 2 trabalhando em cima do Invoke. Vários recursos a serem portados do Fabric 1 informarão as decisões de design do Invoke (para novos recursos ou existentes - por exemplo, a revisão recente da configuração foi um deles), então não quero rotular o Invoke 1.0 até que seja " batalha testado" suficientemente.

Meu plano é ter um alfa do Fabric 2 pronto para o público pelo PyCon o mais tardar (idealmente muito antes) e isso levará ao Fabric 2.0 + Invoke 1.0.

Obrigado pelo esclarecimento, onde posso ajudar?

Estou trabalhando nisso em uma filial privada por um curto prazo até conseguir algo com o qual eu esteja feliz e anunciarei no twitter/mailing list/etc assim que estiver pronto para feedback, então, por favor, fique atento.

Comecei a mudar para invocar em combinação com comandos shell e alguns Paramiko porque fabric é o último pacote sem suporte a python3 no meu projeto

Algum ETA para Fabric 2.0 e Invoke 1.0 como Python 3.5 foi lançado ontem e será o padrão no Ubuntu 16.04 LTS?