Parabéns pelo post, brother!
Uma dúvida honesta: suponha um projeto (1) armazenado em um repositório Git, (2) acessível e usado por outros colaboradores e (3) que tenha um ambiente virtual configurado; seria possível os devs (a) clonarem o repo, (b) ativarem a venv, (c) trabalharem na máquina local e (d) depois commitarem, sem que tenham problemas quanto às bibliotecas, não? Digo isso porque a venv é um aglomerado de arquivos, e como as mudanças são rastreadas ali pelo Git...
Opa, obrigado pela dúvida. Acho ela muito importante.
Creio que eu não tenha sido tão claro quanto eu queria na sessão "persistindo o ambiente". A resposta deveria estar lá.
Seguindo o fluxo de trabalho:
-> Você (dev a). Criou o ambiente, instalou as bibliotecas, desenvolvou a primeira feature e atualizou o requirements.txt para enfim commitar suas alterações. -> O requirements.txt precisa estar no repositório Git também. Assim ele pode ser commitado e "pushado" para o repositório remoto.
-> O dev b vai fazer o clone do projeto com o requirements.txt incluso
-> Ele cria o env local, realiza a instalação das bibliotecas com pip install -r requirements.txt e pode começar a trabalhar.
-> Se ele instalar novas bibliotecas no caminho, é dever dele atualizar o requirements.txt com pip freeze > requirements.txt e commitar o arquivo de requerimentos junto com as demais alterações no código.
Note que isso envolve um grau de responsabilidade para ambos os desenvolvedores, que devem sempre estar atualizando o arquivo de requerimentos.
Quando o número de contribuintes aumenta, aumenta também os pontos de falha para essa metodologia.
Por isso que usar somente o venv para projetos de grande porte já não é mais recomendado.
Eu espero escrever futuramente um artigo sobre o poetry, que é um gerenciador tanto de pacotes quanto de dependências do Python que busca resolver muitos problemas que o pip + ambientes virtuais não conseguem. Ainda estou estudando ele para me sentir confiante em escrever sobre haha.
Espero ter tirado sua dúvida! 😁