Python-future: A nova importação mágica "configparser" quebra o backport "configparser"

Além disso, no repositório do backport, as pessoas já relatam que isso não está funcionando: https://bitbucket.org/ambv/configparser/issue/8/configparser-import-broken-on-py27

Por enquanto, tive que remover a dependência do python-future no configparser para fazê-lo funcionar.

+1

Mais geralmente, o python-future não deve instalar módulos que sombreiam outros módulos instalados IMO. A maioria dos outros são menos prováveis ​​de serem problemas, então pode ser preferível apenas fazer isso em vez de adicionar uma dependência falsa.

@ambv , @Julian : Obrigado pelo seu feedback. Eu gostaria de corrigir isso, mas ainda não vejo o caminho certo para prosseguir. Aqui estão as opções como eu vejo:

1. Remova configparser do python-future e altere os documentos para recomendar o uso do seu pacote configparser . Isso pode fazer sentido, mas não a menos que configparser seja um substituto imediato para ConfigParser no Py2.7. Atualmente, há 14 falhas e 9 erros ao executar test_cfgparser.py no Python 2.7.9 com o pacote configparser instalado após substituir import ConfigParser por import configparser as ConfigParser . Com o python-future e seu simples alias configparser instalado, todos os mesmos testes passam.
2. Altere setup.py em python-future para instalar o pacote de alias configparser somente se um módulo ou pacote com o mesmo nome não existir. A desvantagem disso seria que os pacotes instalados dependeriam da ordem em que são listados em requirements.txt . Pior ainda, acredito que pip não garante a instalação de pacotes na ordem em que aparecem em requirements.txt . Se configparser e future fossem listados, isso faria com que o conjunto de pacotes instalados por pip não fosse determinístico.
3. Use o recurso extras do setuptools para oferecer suporte a uma opção de instalação como pip install future[without_configparser] .

Você acha que o pacote configparser pode ser modificado para que o conjunto de testes do Python 2.7.9 passe ao usá-lo? Isso me daria confiança em recomendá-lo para um caminho de atualização suave para o código Py2 que atualmente usa ConfigParser .

Com o passar do tempo, mais e mais pessoas usam diretamente o backport configparser, porque essa é a maneira de usar a API upstream mais recente (e recursos) enquanto ainda está no Python 2.x.

Assim, eu realmente não entendo a relevância de seus testes reprovados. Se você quiser a API antiga, use o nome do módulo antigo. Se você quiser a nova API, use o novo nome. Não faz mais sentido colocar o ConfigParser 2.x no local onde está o substituto do Python 3.

Seria bom ter uma correção para isso, pois recebi um relatório sobre isso em Kali https://bugs.kali.org/view.php?id=3245 e em um sistema típico Kali Linux tenho pacotes que precisam de python -future e python-configparser. Exceto que o último está quebrado para qualquer um que o use no Python 2.x devido a esse bug.

Então, para resumir, acho que você deve implementar (1) e descartar os testes sobre o configparser. (2) não é uma opção, pois os pacotes Debian são construídos em ambientes mínimos e o python-configparser não estaria disponível quando o setup.py fosse executado. (3) é possível, mas significa que a API do python-future varia dependendo de como foi instalada. Não é realmente uma boa idéia, pois uma distribuição só pode instalá-lo de uma maneira.

Obrigado! cc @sbrun

Atualmente, por exemplo, o Fedora simplesmente corrige o configparser , já que também tem o backport disponível.

FWIW, atualmente estou passando por correções de upstream que preciso mesclar ao backport e lançarei o backport 3.5.1 do configparser amanhã. Quanto ao python-future, também acho que deve implementar (1).

Grato a todos pela sua colaboração!

Estou disposto a remover configparser do python-future na v0.16. Eu tenho uma ramificação em andamento: https://github.com/PythonCharmers/python-future/tree/v0.16.x.

Eu vim aqui tentando descobrir porque ConfigParser.read_dict parou de funcionar na minha máquina.

Acontece que um dos pacotes que eu uso começou dependendo de python-future (especificamente alguma parte do QGIS), e então fui atingido por esse problema porque a versão do ConfigParser no Python 2.7 não implementa a API completa do ConfigParser em Python 3.x.

Resolvi isso bloqueando a versão python-future do pacote:

sudo chmod 000 /usr/lib/python2.7/dist-packages/configparser/

Flake8 recentemente adicionou uma dependência no backport configparser que @ambv mantém generosamente. Alguns usuários também tinham este módulo instalado que quebrou o comportamento existente, testado e documentado do Flake8. Isso é um problema para nós, e agora vou começar a adicionar documentação ao Flake8 para explicar por que as pessoas podem ver um problema. O futuro será mencionado especificamente para ajudar os usuários a evitar esse incômodo.

@sigmavirus24 Ian, você pode contornar isso por enquanto dependendo do backport configparser e usando o formulário from backports import configparser . Isso foi implementado especificamente para desbloquear situações como estas :(

@ambv obrigado! Eu não sabia que eu poderia fazer isso.

Agora lancei a v0.16.0, que remove configparser . Os documentos também recomendam o uso do backport de Lukasz. Obrigado pela sua opinião a todos!

Obrigado @edschofield!