Laguinho CLI

[thayannevls]

Issue destinada a discussão técnica de maneira geral, deverá ser quebrada em outras issues depois.

Discutimos aqui OpenDevUFCG/laguinho-api#31 e concordamos na criação de uma CLI para o laguinho. Ela terá funcionalidades de:

• Publicar dados a partir do seu repositório do seu projeto
• Consumir dados de outras pessoas

Em resumo laguinho publish <dado> e laguinho get <dado>.

Agora vem as questões técnicas:

1. Criaremos um repositório separado? Resposta: Sim! Estamos nele agora 😆
2. Qual linguagem será usada? Python é uma forte candidata. Resposta: PYTHON!
3. Que bibliotecas podemos utilizar?
4. Quais inspirações de CLI podemos estudar? Coloquem links aqui
5. Quais serão os passos iniciais

[JoseRenan]

1. Acho que um repositório separado sim, afinal as tasks da CLI vão ser independentes da do back no geral, tirando as que precisarão de endpoints do back. Só precisamos ver como fica as discussões, talvez tenha discussões que interfiram em ambos os projetos, se é OK fazer isso em repos separados

2. Python é uma forte candidata, gosto de Go pq Go é top kkkkkkk e pq pode contar com algumas facilidades pra distribuir a CLI, mas acho que se a gente quiser contribuições de pessoas de todos os períodos do curso, a gente vai abrangir mais gente com python mesmo

[JoseRenan]

Sobre as inspirações, o próprio Go tem uma CLI pra baixar dependencias e bibliotecas, semelhante ao pip ou npm, só que no Go você não tem um registry, ele vai buscar a dependencia direto na URL do repositório, por exemplo go get github.com/OpenDevUFCG/laguinho-api vai clonar o repositório do laguinho no seu workspace Go, algo mto semelhante ao que pretendemos fazer

O próprio NPM e Yarn servem como inspiração por manter um arquivo de metadados sobre o pacote que está sendo desenvolvido e também pela CLI incrível que eles tem. No NPM/Yarn você consegue definir quais diretórios você quer que sejam baixados no npm install ou yarn add, seria bom termos algo semelhante pra evitar baixar código desnecessário no laguinho get

[thayannevls]

Tem link dessa do Go Renan?

Bem acho que dá pra criar o repositório, e usar a feature do github de transferir essa issue para lá. :)

Adiantando:

• Quanto a ele poder pegar mais de um dado, era legal a gente dar suporte no comando de get pra que pasta ele deseja jogar os arquivos
• Vamos discutir a estrutura do arquivo numa issue, npm e yarn ctz inspirações
• vamos fazer um roadmap, por favooor!!!! Sou doida pra fzr roadmap de um projeto igual outras orgs fazem kkkkk

[JoseRenan]

vamos fazer um roadmap, por favooor!!!! Sou doida pra fzr roadmap de um projeto igual outras orgs fazem kkkkk

Tens algum modelo de roadmap aí???

[thayannevls]

É simples

https://github.com/vuejs/vue/projects/6
https://github.com/RocketChat/Rocket.Chat#roadmap
https://reactjs.org/blog/2018/11/27/react-16-roadmap.html

Tanto faz a forma que faz também

[thayannevls]

Cria o repo @JoseRenan

[JoseRenan]

Pronto, @thayannevls e @/all, o repo da cli já está vivo!!! vamo discutir as issues referentes a CLI lá agr

[JoseRenan]

Sobre as bibliotecas, se usarmos python, a click é muito boa e bem simples de usar. Se usarmos Go, o ideal é a lib cobra.

Pra distribuir tem duas opções:

1. Em caso de python usar o setuptools e disponibilizar no pypi pra baixar via pip (não gosto dessa opção porque acho que tem treta de python2, python3, pip, virtualenv, mas tbm não sei se é um empecilho)
2. Gerar um executável e um script de instalação (nativamente no caso do Go, e no caso de python, usando pyinstaller, ou alguma outra lib, só conheço o pyinstaller msm, se alguém tiver mais alguma ideia, manda link!!!!)

[JoseRenan]

/cc @paulojbleitao @eduhique @ArthurFerrao @grabowski74

[thayannevls]

Precisa usar biblioteca pra fzr command line? No caso, se vale a pena

[JoseRenan]

Assim, fica bem organizado e já trata facilmente a parte de args e documentação, acho que só isso já vale a pena 🤔

[thayannevls]

São pontos bons, mas tem desvantagens depender de libs e sua implementação, ainda mais as de python que geralmente são novinhas e não tem comunidade grande

[JoseRenan]

Qual das? Tipo o click já é bem estabelecida, inclusive o flask usa pra CLI deles, o pyinstaller que não sei direito, inclusive preciso de opiniões pq pra mim é o único motivo de ainda não bater o martelo pra usarmos python :(

[thayannevls]

hmm, já que o flask usa tudo bem então. É porque já usei algumas libs python q perdeu suporte, fico traumatizada XD

[thayannevls]

Não vejo vantagens técnicas que façam uma linguagem se sobrepor a outra no nosso caso. Então parte pra gente pensar no contexto, python talvez seja mais acessível para alunos da ufcg. Se for Go, dá uma oportunidade legal pro pessoal da UFCG ter um primeiro contato com a linguagem, só que significa que ter contribuintes é mais difícil.

Trade-off ai, make your choice @JoseRenan @paulojbleitao @eduhique @ArthurFerrao @grabowski74

[thayannevls]

Depois que os meninos comentarem, dá assign neles tbm @JoseRenan só pode dps q comenta

[JoseRenan]

Não vejo vantagens técnicas que façam uma linguagem se sobrepor a outra no nosso caso.

Eu pensei no caso de distribuir mesmo, tipo, os trade-offs que temos com python é:

• pip (acredito que possa vir a ter problema dependendo da versão do python, pelo menos eu já tive 🤔 )
• snap (ajuda bastante pra usuários ubuntu, dificulta um pouco pra outros usuários linux e mata windows users)
• pyinstaller (gera executaveis pra todos os OSs, mas não conheço muito a biblioteca)

[thayannevls]

@JoseRenan sobre a versão do pip, acho que a comunidade já criou formas de overcome isso.

Olha essa cli do codesandbox, muito legal pra gente se basear.

Essa parte de importar com o github também é legal

[paulojbleitao]

Eu acho que não deve ter muito problema com o pip, pelo menos da minha experiência foram poucos os casos que tive problema com versionamento 🤔

Como o próprio pip faz pra rodar?

[JoseRenan]

Como o próprio pip faz pra rodar?

É pq tipo, o pip do python2 só baixa coisas do python2, o pip do python3 só baixa coisas do python3, pra alguns o do python3 já é o default, pra outros nn

[thayannevls]

@JoseRenan usaríamos python3 para desenvolver, então qualquer possibilidade de suporte ao python2 é descartada, não sendo um problema do pip em si. É comum que hoje em dia novos projetos usem python3 e pip3, python2 e pip2 vai ficar obsoleto.

[paulojbleitao]

É pq tipo, o pip do python2 só baixa coisas do python2, o pip do python3 só baixa coisas do python3, pra alguns o do python3 já é o default, pra outros nn

Sim, a minha dúvida é mais como o próprio pip roda. Ele tem um executável ou coisa assim? Porque se tiver a gente pode olhar como eles fazem

É comum que hoje em dia novos projetos usem python3 e pip3, python2 e pip2 vai ficar obsoleto.

Isso é verdade, tem um problema que a gente vê python 2 no curso né, mas a transição é bem tranquila

[thayannevls]

Vamos quebrar as issues pessoal

[fanny]

É, acho que Go podia ser uma opção mesmo, vejo muito use cases de cli nela, e acho que quanto ao aprendizado pelo que vi ela é bem compacta então acho que isso contribue pra não ter uma curva tão grande de aprendizado, e pelo que sei a comunidade encoraja muito você a usar standard libraries, assim não teríamos esse problema de manutenção de pacotes que a gnt usa. Quanto a atratividade em relação a novos contribuidores, eu sei que na graduação existe uma disciplina que usa, que é concorrente, essas pessoas poderiam se interessar.

[paulojbleitao]

Quanto a atratividade em relação a novos contribuidores, eu sei que na graduação existe uma disciplina que usa, que é concorrente, essas pessoas poderiam se interessar.

O problema é que concorrente é bem pro final do curso, aí o projeto ficaria bem menos acessível mesmo

[JoseRenan]

Fechando issue em decorrencia dos pontos que foram discutidos em reunião aberta:

Bibliotecas: usaremos click para a CLI
Roadmap das versões até a 1.0 será planejado após a estruturação inicial do projeto