Anaconda 2 Quem Sobrevive

Entendendo o ecossistema Anaconda após a versão 2

A pergunta que aparece nos fóruns técnicos sobre anaconda 2 quem sobrevive reflete algo real: muita gente travou na migração e ainda não resolveu. A situação começou quando a Anaconda Inc. parou de dar suporte pleno ao Python 2 em seus pacotes mais recentes, mas o legado ficou espalhado por mil repositórios corporativos. O que resta funciona? O que quebra em produção? Vou explicar baseado no que vi acontecer em pelo menos dez projetos diferentes. Se você ainda mantém código rodando sobre Python 2.7 com Anaconda, basicamente existem três grupos. O primeiro é quem já migrou para o Python 3.8 ou superior e esqueceu o passado. O segundo grupo tentou manter compatibilidade dupla e agora vive num inferno de dependências conflitantes. O terceiro grupo simplesmente não sabe que precisa migrar até o dia em que um patch de segurança deixa de chegar. O problema prático que eu enfrentei foi específico. Tinha um pipeline de processamento de dados legados que usava o pacote sklearn (versão 0.19) rodando num ambiente Anaconda criado em 2017. Quando resolvi atualizar o conda para fechar uma vulnerabilidade, o comando conda update --all quebrou três bibliotecas inteiras. O workaround que funcionou foi congelar o ambiente com conda env export, restaurar de um backup do arquivo YAML e depois aplicar migração gradual biblioteca por biblioteca, não tudo de uma vez. Levei cerca de quatro horas num sábado.

Para quem ainda quer rodar algo funcional com versões antigas, a saída mais segura é usar contêineres Docker com imagens fixas. Eu mantenho uma imagem base continuumio/anaconda3-2019.10 que roda exatamente o que era estável naquela época. Isso elimina a variável "atualização automática quebra tudo" do processo.

O que funciona e o que não funciona em 2024

Não existe uma resposta única porque depende do seu stack. Pacotes puramente científicos como NumPy 1.16, Pandas 0.24 e Matplotlib 3.1 ainda instalam sem dor no Python 2.7. O problema real começa com bibliotecas que dependem de C extensions compilados ou que têm wrappers modernos que só existem para Python 3. TensorFlow 1.x roda, mas com limitações sérias de hardware. PyTorch não tem mais suporte oficial a Python 2, então se seu modelo depende disso, precisa manter uma versão antiga do framework ou migrar o código. Aqui vai uma informação que muitos não consideram: o conda em si não é o problema. O problema é o canal default da Anaconda. Eles migraram as builds para Python 3 e o índice de pacotes para Py2 simplesmente parou de receber atualizações em março de 2020. Isso significa que qualquer pacote que você tentar instalar hoje via conda buscando compatibilidade com Python 2 vai encontrar uma versão desatualizada de 2019 ou um erro de dependência irresolúvel. A solução técnica é adicionar o canal https://conda.anaconda.org/anaconda-fossil que mantém builds antigas, mas mesmo esse canal não é atualizado regularmente. Um insight contra-intuitivo que aprendi na prática: muitos desenvolvedores acham que usar pip install dentro de um ambiente conda com Python 2 vai resolver. Na verdade, isso frequentemente cria conflitos piores porque o pip ignora o solver do conda e instala pacotes que quebram a árvore de dependências gerenciada. Se for usar pip em ambiente conda antigo, always use conda install primeiro para as dependências de baixo nível e deixe o pip apenas para pacotes que realmente não estão no conda.

Migração na prática

Se você precisa migrar, o caminho mais direto passa por três etapas. Primeira, identifique todos os ambientes conda ativos com conda env list e exporte cada um antes de qualquer mudança. Segunda, use a ferramenta python-modernize ou 2to3 para converter automaticamente a sintaxe do código Python 2 para Python 3. Terceira, recrie os ambientes com Python 3.8+ e resolva dependências uma a uma. O comando básico para testar compatibilidade antes de migrar production é criar um ambiente paralelo: conda create -n py3_legacy_test python=3.8

Depois migre os pacotes um por um e execute seus testes unitários contra o novo ambiente. Eu recomendo fortemente não pular essa etapa porque erros de sintaxe são fáceis de corrigir, mas erros de comportamento em tempo de execução (como mudança no comportamento de divisão de inteiros ou ordem de iteração em dicionários) podem passar despercebidos até causar bugs em produção. Uma limitação importante que precisa ser dita claramente: se seu projeto depende de bibliotecas empresariais muito específicas que nunca foram portadas para Python 3, migração pode não ser viável sem refatoração profunda. Nesses casos, manter um servidor dedicado com Anaconda 2 e Python 2.7 isolado da rede é a única opção sensata, mesmo que isso signifique operar com riscos de segurança conhecidos. Nada disso é bonito, mas é a realidade que quem trabalha com legado precisa aceitar.