A ideia desse projeto é já ser um "start" para seu projeto python. O que temos aqui são configurações pré prontas para que você possa se dedicar inteiramente ao código do seu projeto.
O Pipfile já vem com alguns scripts que ajudam nas tarefas do dia a dia e nas checagens do CI.
-
pipenv run test
Roda os testes do projeto. Esse script está configurado para medir a cobertura do pacote
brandenburg
. Esse pacote deve ser ajustado para o pacote onde seu código vai ficar. -
pipenv run lint
Roda o
mypy
para fazer checagem estática de tipos no código. -
pipenv run fmt
epipenv run fmt-check
Roda o black para formatar o código. O comando
pipenv run fmt-check
apenas checa se alguma formatação seria necessária. É útil para rodar no processo de CI. -
pipenv run isort
epipenv run isort-check
Formata o código ordenando os imports usando o projeto isort. O comando
pipenv run isort-check
apenas checa se algum import precisa ser reformatado. É útil para rodar no processo de CI.
Ao instalar o pre-commit
, todas as vezes que realizar um novo commit, será checado todos os pontos de qualidade do
codigo, como codestyle, testes, imports e por aí vai.
Os comandos abaixo devem ser executados apenas quando é feito o clone do projeto.
pre-commit install
pre-commit install --hook-type pre-puh
Esse repositorio já possui alguns workflows do Github Actions pré-configurados. Os workflows são:
-
.github/workflows/pull-request.yaml
Esse workflow roda em cada PR aberto no projeto. Roda os testes em múltiplas versões do python e faz checagem de formatação de código, lint (com mypy) e formatação de imports (com isort).
Esse workflow faz também upload do relatório de coverage para o codeclimate. Perceba que o upload é feito em apenas um versão do python, isso porque o codeclimate rejeita múltiplos upload para um mesmo commit, então precisamos escolher uma das rodadas de teste para fazer o upload.
Para que o upload para o codeclimate funciona você precisa criar um token no CodeClimate e colocar esse token como um secret no seu repositório. O Nome do secret deve ser:
CC_TEST_REPORTER_ID
. Mais sobre a documentação do codeclimate com githubactions: https://docs.codeclimate.com/docs/github-actions-test-coverage
Esse projeto já vem com o release-drafter configurado. Dessa forma, a cada PR megeado na branch main
(e também na master
para repositório legados) uma Release Draft será atualizada mencionando esse PR.
Para fazer uso dessa opção, basta criar quatro labels em seu projeto:
feature
bug
docs
breaking-change
Todos os PRs que tievem uma (ou mais) dessas labels e forem mergeados pra branch principal, uma release Draft será automaticamente atualizada.
Essa configuração do release-drafter também já calcula a próxima versão baseado no SemVer. A configuração é a seguinte:
- A label
breaking-change
aumenta amajor
version; - A label
feature
aumenta aminor
version; - A label
bug
aumenta apatch
version; - PR sem label também aumenta a
patch
version;
Não se esqueça de de ajustar o links para o seu projeto no arquivo .github/release-drafter.yml
.
Para facilitar na criação de um novo serviço e seguindo as boas práticas definidas no 12factors sobre configurações. Adicionamos o uso no pydantic para criar e validar essas informações para nós.
Exemplo de uso:
from config import settings
print(settings.DEBUG)
Para configurar uma variável de ambiente é necessário ficar atento ao prefixo.
o default do projeto verificar inicialmente para uma variável de ambiente chamada NAMESPACE
caso não a
encontre o prefixo será DEV_
, o que isso significa?
O uso ficará da seguinte forma quando configuramos o namespace sempre adicionaremos o prefixo no momento de exportar as variaveis de ambiente.
NAMESPACE=PROD PROD_DEBUG=False python main.py
Caso não definimos nenhum namespace, o prefixo será DEV
, ou seja
DEV_REDIS_PORT=1234 python main.py
Lembrando que dentro da sua aplicação o que vale é justamente o nome que foi definido no arquivo config.py, sem o prefixo.