add api wrappers

[aassumpcao]

pessoal, queria abrir a discussão para incorporar o módulo do @rennerocha aqui, que tal?

[rennerocha]

Eu não acho que o módulo que eu fiz deveria estar aqui. São objetivos diferentes na minha opinião. Quem utilizar o toolbox está preocupado em como extrair os dados dos PDFs (OCR, etc), em como inserí-los na base de dados, precisa instalar o Java, Apache Tika.

O módulo que eu fiz é para quem quer simplesmente acessar os dados que temos disponíveis, sem se preocupar em como eles foram criados. É para um usuário não tão técnico possa fazer um pip install api-wrapper e começar a usar os dados em um Jupyter Notebook, sem ter que instalar outras coisas.

[aassumpcao]

@rennerocha, acho que você tocou em vários pontos importantes. O primeiro deles é com o uso do Toolbox, que requeria instalar um monte de coisa mesmo só para começar a analisar o conteúdo dos diários. Felizmente, agora eu já implementei uma solução de extração de dados que independe de instalação local do Tika. A extração com Tika local persiste como segunda opção, mas agora a extração principal é via Tika Server, que faz chamadas a uma REST API do Tika que rodaremos num droplet da Digital Ocean (certo @jvanz e @sergiomario?). Faltam poucos detalhes para eu enviar a PR com essa funcionalidade para o @jvanz. Acho que isso alivia um pouco sua primeira preocupação.

Na segunda parte, acho difícil a gente dizer qual é o interesse das pessoas usuárias no Toolbox ou API de dados sem termos uma amostra de pessoas testando. Minha intuição seria dizer que tanto API quanto Toolbox já são muito técnicas para o público em geral, que usuária mais a plataforma web do que os pacotes em Python. Nesse sentido, botar o wrapper da API e o Toolbox no mesmo lugar parece fazer sentido para mim. Por fim, acho que o @sergiomario levantou essa bola em outro lugar e seria muito bom ter tudo num lugar só. Tipo, só tem um lugar para visitar para quem quiser trabalhar tecnicamente com o QD, que no meu pensamento é o Toolbox. Aí, a pessoa faz uso customizado, e.g.:

from queridodiario_toolbox import Gazette
from queridodiario_toolbox import API

O que você acha? Não sei se tem regra para isso, mas eu sigo achando que temos de ter um wrapper para a API dentro do Toolbox. Inclusive, acho que um Toolbox em R é fundamental, já que ela é uma das principais linguagens para análise de dados. O pessoal da @abjur, com quem trabalho, já está fazendo o wrapper em R baseado no seu; as outras funcionalidades pretendo implementar mais para frente.

[jvanz]

Acredito que as duas perspectivas tem seus argumentos válidos. Meu instinto inicial seria separar. Porém, o conceito do toolbox é de "all baterries included". Ou seja, quando alguém quisesse fazer algum tipo de analise precisaria apenas do toolbox. A lib daria uma forma de acessar o dados e algumas maneiras básicas de processar esse dado. Por isso, no caso do toolbox também existe certo sentido em ter algo incluso dentro da lib.

Estava refletindo sobre isso. Acho que precisamos consultar que pretendemos atender, cientistas de dados. Ver o que eles acham melhor. Se eles falarem que tendo um pacote instalável via pip ou gerenciador de pacote, não importa muito onde o código fique. E podemos tornar o toolbox em um repo de compartilhando de analises. Se eles preferem tudo em uma única lib, podemos adicionar o wrapper na lib.

A extração com Tika local persiste como segunda opção, mas agora a extração principal é via Tika Server, que faz chamadas a uma REST API do Tika que rodaremos num droplet da Digital Ocean (certo @jvanz e @sergiomario?).

Não pretendo ter uma API REST aberta para o usuário externo. Esse serviço será utilizado apenas pelos nosso programas. Deixar algo desses aberto vai causar custos sem necessidade. Porém, está sendo planejada uma alteração no projeto para ter um arquivo txt com o conteúdo dos diários. Assim, o usuário não precisa extrair o texto localmente. Tudo pode ser pego no mesmo lugar que o arquivo original. Isso foi uma alteração pedido pelo pessoal que está trabalhando na interface do Querido Diário e vai ser feita. Isso não significa que precisamos tirar os extratores de texto da lib. Eles podem estar lá. Mas vai ser precisa uma configuração para utiliza-los. Além disso, se julgarmos necessário, podemos resolver esse problemas empacotando todas esses dependências e fornecendo uma maneira fácil de instalar para o usuário através de repositórios de pacotes. O Open Build Service, por exemplo, permite fazer o build para múltiplas distros.

[cuducos]

Chegando de fora:

Porém, o conceito do toolbox é de "all baterries included". Ou seja, quando alguém quisesse fazer algum tipo de analise precisaria apenas do toolbox.

É esse o propósito da toolbox? Eu sinceramente, não sei. E, se tiver um “um arquivo txt com o conteúdo dos diários” isso não seria infinitamente mais prático do que uma toolbox tanto do ponto de vista de quem consome os dados quanto do ponto de vista de quem mantém o projeto?

Quem consome os dados não precisa se preocupar com tesseract, tika etc. Não precisa de preocupar com Python se sua outra linguagem. É só baixar um arquivo texto e sair usando. E, para quem mantém, é uma coisa a menos para manter : )

[aassumpcao]

Acho que esse issue caducou com o wrapper vivendo fora da toolbox.