- Em favor do padrão singleton que cria um Baobaxia no módulo original

- Contém refactoração de vários elementos ligados direta e indiretamente à autorização.

Saci Pererê authored 1 year ago and Saci Pererê committed 1 year ago

Testes utilizam Mucua localizada nas fixtures

- Quando realizavamos a importação direta da aplicação para rodar um
cliente nos testes. Esta vinha com a chamada padrão da Baobáxia
`Baobaxia()`, a qual é configurada com parâmetro presentes no diretório
do usuário do SO.

- Desta forma não teríamos como utilizar cenário reprodutíveis nos
testes.

- Principais modificações:
  - A classe BaobaxiaAPI foi transformada em uma dependência e reescrita
  durante os testes utilizando a função `app.dependency_overrides`
  - A classe BaobaxiaAPI torna-se chamável `__call__` para possibilitar
  mantermos o padrão Singleton garantido pelo import de um objeto
  definido em um módulo. De outra forma seria necessário retornar
  através de funções, o que iria quebrar o padrão Singleton. E
  consequentemente as sessoes.
  - A classe BaobaxiaAPI pode receber um objeto da classe Baobaxia como
  parâmetro, permitindo variação das configurações da aplicação.

- Modificações adicionais:
  - Cria opção para pular a configuração do instalador
  - SaberConfig é agora um BaseSetting (pydantic)
  - Cria configuração global da aplicação
  - Add pydantic-settings
  - Uso da biblioteca Loguru
  - Update dependencies
  - Permite que `main.py` seja executável diretamente

Cria pipeline com definição para execução de testes unitários.

No runner foram instalados:
- git-annex
- pipx
- poetry

This reverts commit 4d32582a.

Cria pipeline com definição para execução de testes unitários.

No runner foram instalados:
- git-annex
- pipx
- poetry

Saci Pererê authored 1 year ago and Saci Pererê committed 1 year ago

- Recomendação de não usar: `if not ELEMENTO in LISTA`
- Seria mais adequado `if ELEMENTO not in LISTA`

- Modifica Makefile para usar Poetry
- Remove arquivos de requirements
- Adiciona precommit para normalizar estilo (lint)

O entrypoint da aplicação estava dentro do módulo acervo, causando a mistura em um mesmo módulo:

1. Definição do `entrypoint` da aplicação
1. `modelos` de mídia
1. Geração de dinâmica de endpoints

* O caso (1) foi endereçado com a criação do arquivos `main.py`
* Para caso (2) foi criado um pacote `models` para onde passamos as definições dos modelos, o de mídias especificamente está em `models/midias.py`
* No caso (3) foi feito o redirecionamento para um pacote específico com as definições de endpoints: `api/v2/endpoints`
  * Para as mídias foi mantido o formato de criação "dinâmica" dos endpoints, sendo necessário revisitar posteriormente
  * Aproveitamos para passar os demais endpoints que se encontravam no módulo `rest.py` para o mesmo pacote.

Outra citações importantes:

* Mudar a referência relativa nos imports ( uso de "." ou ".." ), usar baobaxia como raiz das referências.
* Não usar "\*" nos imports
* Criação de um módulo `contants.py` para agrupar as contantes provisoriamente. Enquanto não estruturamos melhor um módulo de configurações