<p>pip install - editável e pip install clash para pacotes de namespace</p>

O mesmo problema aqui :(

Publiquei um código para testar esse bug: http://public.hg.stephane-klein.info/hgwebdir.cgi/test_pip_namespace_bug_3/

A raiz do problema aqui é que as ferramentas de instalação incluem dois métodos para fazer os pacotes de namespace funcionarem: o método __init__.py (que é documentado e pode ser usado por humanos) e o método ...-nspkg.pth file, que é usado apenas com --single-version-externally-managed (que o pip usa). Os dois métodos não são compatíveis um com o outro.

Depois de alguma discussão com mitsuhiko e outros no IRC, parece que a melhor solução (parcial) para o pip é fazer com que "pip install -e" adicione uma versão modificada das ferramentas de instalação padrão ... arquivo nspkg.pth para cada pacote instalado de desenvolvimento . (As modificações necessárias são usar o caminho do ovo-link de desenvolvimento em vez de sitedir, e pular a verificação de init .py inteiramente, uma vez que um pacote de espaço de nomes instalado para desenvolvimento terá um init .py). Isso significa que o pip será pelo menos compatível consigo mesmo (pacotes de namespace instalados com pip e instalados com pip trabalharão juntos). Os pacotes de namespace instalados por Pip e setuptools / distribuir não serão compatíveis.

Recentemente fui mordido por isso também. Outro problema causado por ele é que, uma vez que __init__.py não está instalado para o pacote de namespace (assumindo que você instalou apenas um pacote naquele namespace, e ele foi instalado - única-versão-gerenciado externamente). quebra a pesquisa de módulo do nariz. Talvez seja culpa do nariz, mas ainda acho que é razoável esperar que, se um diretório não contiver um __init__.py , não seja um pacote Python.

Eu acho que o pip deveria de alguma forma simplesmente matar o nspkg.pth completamente e instalar o __init__.py . Contanto que o próprio pacote seja projetado corretamente (ou seja, o __init__.py está vazio, exceto para extend_path / declare_namespace), não deve ser um problema. - single-version-externally-managed foi projetado com os empacotadores do sistema em mente, mas eles não usarão o pip em primeiro lugar. Então, eu me pergunto se há alguma maneira de desativar esse comportamento sem ser muito intrusivo.

+1 para mudar de '- single-version-externally-managed': essa opção não se destina a casos de uso do pip. Se o pip não consegue fazer um trabalho pelo menos tão bom na instalação de coisas quanto o easy_install, qual é o seu propósito?

Mudar totalmente de --single-version-externally-managed não vai acontecer; instalações planas são um recurso. Abandoná-lo apenas no caso de pacotes de namespace é uma possibilidade que eu consideraria para evitar esses problemas. Eu não gosto disso, mas não parece haver nenhuma ótima opção, dada a incompatibilidade inerente entre os dois tipos de suporte de pacote de namespace integrado ao setuptools / distrib.

Dizer que --single-version-externally-managed "não se destina aos casos de uso de pip" é algo entre o errado e um arenque vermelho. O sinalizador destina-se a permitir instalações simples de versão única, gerenciadas por alguma ferramenta diferente de easy_install. É exatamente para isso que o pip o usa; o fato de que o autor do setuptools originalmente (e incorretamente) pensou que apenas os empacotadores do sistema estariam interessados ​​em tal recurso é irrelevante.

A quebra aqui é um bug inerente à técnica que setuptools usa para pacotes de namespace com esse sinalizador, e o bug está tão presente quando o sinalizador é usado por seu público originalmente pretendido, empacotadores de sistema (eu vi o bug pela primeira vez na interação entre setup.py Develop "pacote instalado e um pacote de namespace instalado pelo pacote do sistema).

Também estou enfrentando esse bug. Acho que esse é um daqueles insetos insolúveis que vieram para ficar. Ah bem.

Eu aceitaria um patch para evitar --single-version-externally-managed quando um pacote de namespace está envolvido, o que acho que resolveria esse problema. Atualmente, não tenho planos de escrever esse patch.

Por que não uma opção que podemos passar para pip install não usar --single-version-externally-managed ? Eu testei comentando que em ./pip/req.py:568 e todos os pacotes agora instalados no diretório do ovo, assim como o easy_install faz. Às vezes eu quero fazer isso se usei pip e easy_install para que meu site-packages não se misture com alguns pacotes install flat e outros não.

Não vejo um problema com a opção --egg de cancelar --single-version-externally-managed .

https://github.com/k4ml/pip/commit/93cd6b16207d2eba201a7fc3126624b616f5e6f9

Alguém pode comentar se estou indo na direção certa? Esta é minha primeira vez hackeando o código pip, então isso é baseado em alguns minutos que vislumbrei parte dele, apenas para fazer pip install --egg somepackages instalar tudo em um único diretório de ovo.

Alguém pode comentar se estou indo na direção certa?

Parece bom para mim, só precisa de um teste. Os testes são principalmente de alto nível
testes de integração usando ScriptTest, deve ser fácil de escrever um baseado em
exemplos existentes. Neste caso, você vai querer apenas testar a instalação
um pacote de amostra resulta em um arquivo .egg, não uma instalação simples, em
pacotes de sites. Você deve instalar um pacote do sistema de arquivos local,
não a rede: tests/packages/FSPkg provavelmente funcionará bem. Adicionando
o teste para tests/test_basic.py está ok.

Obrigado!

Solicitações pull - https://github.com/pypa/pip/pull/541

Também estou pensando em tornar possível definir esse sinalizador no pip.conf. O que você acha disso?

Também estou pensando em tornar possível definir esse sinalizador no pip.conf. O que você acha disso?

Vamos discutir sobre a solicitação de pull.

Solicitação pull mesclada nº 541, que fornece uma solução alternativa. Obrigado @ k4ml!

Aviso: a opção --egg , que foi adicionada para corrigir esse problema, pode ser potencialmente removida, sem nenhuma solução alternativa oferecida. Veja a discussão em # 1749

Aqui está um script para realmente reproduzir esse problema

https://gist.github.com/Ivoz/d9bff05069e0ec53e6ea

não sou um grande fã da solução --egg, mas é necessário que haja uma solução menos complicada para isso.

sem uma solução alternativa, durante o desenvolvimento, não posso usar --editable uma vez e depois apenas editar e testar. toda vez que salvo meu código, preciso executar pip install -I --no-deps . que fica muito antigo e frágil (leia-se: às vezes eu esqueço).

parte do problema com a forma como toda essa questão se manifesta é que ela é silenciosa. você simplesmente não pode importar um módulo, mesmo que ele esteja instalado e o pip diga que está lá.

seria um passo positivo apenas fazer pip reclamar se tentar instalar pacotes editáveis ​​como parte de um namespace onde um pacote não editável nesse namespace já está instalado. ou, alternativamente, reclamar se estiver tentando instalar um pacote não editável que faz parte de um namespace onde um pacote editável nesse namespace já está instalado.

outra opção, se realmente quisermos que os pacotes de namespace e as instalações editáveis ​​sempre funcionem, pode ser que se um pacote de namespace for instalado como editável, o pip poderá reorganizar todos os outros pacotes nesse namespace como editáveis ​​junto com o pacote desejado.

Enviei 2 propostas para corrigir esse problema em setuptools https://bitbucket.org/pypa/setuptools/issue/250/develop-and-install-single-version. PARA SUA INFORMAÇÃO.

colocando

import pkg_resources; pkg_resources.fixup_namespace_packages ('')

em um arquivo .pth em pacotes de sites parece suficiente para fazer com que as coisas instaladas do pip install -e funcionem corretamente.

Isso também afeta dois pacotes com o mesmo namespace superior com ambos instalados como editáveis. A segunda instalação do pacote foi interrompida.

Usamos um namespace global para todos os nossos aplicativos e, portanto, este problema é um pouco difícil (+ o problema de que as ferramentas de configuração não suportam rodas, que são necessárias devido à falta de um compilador em nossas plataformas de implantação do Windows). Além disso, todas as soluções recomendadas parecem falhar em nossa configuração com Python 3.4.

Depois de perceber que pip install -e executa setup.py develop para o projeto que deve ser editável, me conectei ao procedimento setuptools e escrevi um arquivo * .pth, que "introduz" os pacotes de namespace durante o processo python começa. Isso resolve o problema para nós ao usar o setuptools 18 e o pip 7.1.0.

Um exemplo de arquivo setup.py, que mostra como isso pode ser feito, pode ser encontrado aqui:
https://gist.github.com/cbrand/a1624ac3e9c81ce45fcb

Espero que isso seja útil para outras pessoas também.

Também encontrei este hoje, e ele está me impedindo de alternar de buildout para virtualenv + pip.

Criei uma pequena demonstração para demonstrar o problema. Para testá-lo, descompacte o .tar.gz e execute o script {{run-me}} dentro dele. Pode ser útil ao testar uma correção.

Eu também estou acertando esse problema.

Ao tentar entender, me deparei com a solução proposta por @carljm em https://github.com/pypa/pip/issues/3#issuecomment -1659959, ou seja, _have "pip install -e" adiciona uma versão modificada do padrão setuptools ... arquivo nspkg.pth para cada pacote instalado de desenvolvimento_.

Eu experimentei essa abordagem manualmente e parece funcionar bem. Parece que ao mesmo tempo resolveria a questão das árvores de origem rasas com pacotes de namespace ausentes, conforme descrito em # 3160.

Portanto, estou me perguntando se essa abordagem ainda é considerada válida, se houve alguma tentativa de implementá-la e se um patch para isso seria considerado?

Então ... não há esperança de que este seja consertado em um futuro próximo?

Algum efeito colateral de pkg_resources.get_distribution() faz a importação funcionar. Descobrimos isso quando o código que carregava os pontos de entrada funcionava corretamente enquanto o shell python falhava.

Isso também pode explicar por que um shell ipython não tem problemas para importar os pacotes.

Estou surpreso que esse bug ainda esteja aberto sem uma solução clara após 5 anos.

Se o seu trabalho é colar as estruturas em uma estrutura unificada, o pip torna seu trabalho uma merda. Sinceramente, não tenho ideia de como prosseguir com meu trabalho devido a esse bug.

Este é um problema difícil de resolver em projetos feitos principalmente por voluntários,
Sinta-se à vontade para adicionar o suporte necessário nas ferramentas de configuração para que o pip possa fazer isso corretamente

Brandon Github [email protected] escreve:

Estou surpreso que esse bug ainda esteja aberto sem uma solução clara após 5 anos.

Sim, é uma pena.

Se o seu trabalho é colar as estruturas em uma estrutura unificada,
pip faz seu trabalho ser uma merda. Sinceramente, não tenho ideia de como prosseguir com
meu trabalho devido a esse bug.

Recentemente apliquei o hack fixup_namespace_packages ('') mencionado acima e
parece funcionar: criei um z.pth dentro dos pacotes de sites do venv
contendo apenas import pkg_resources; pkg_resources.fixup_namespace_packages('')

Vale a pena tentar, IMHO.

Só mais um solavanco aqui!

Vou apenas mencionar que cada pacote de medula utiliza namespaces (alguns pacotes populando até quatro ou cinco) e que este problema específico tem sido um pouco uma desgraça da minha existência quando se trata de ajudar novos usuários a se preparar com ferramentas de desenvolvimento . Eu tenho apenas 60 pacotes usando isso. A nota entry_points também é interessante, já que virtualmente todos os pacotes que contribuem para um namespace também contribuem com entry_points .

A abordagem pip só funciona, em minha experiência, se _todo_ pacote estiver instalado, editável, do disco, que coopere no namespace. Se um pacote for instalado não editável via pip, todo o novelo começa a se desfazer com alguns sintomas muito, muito obtusos para novos usuários. (Como módulos importáveis ​​intermitentemente; uma verificação geral de sanidade de importação do namespace pai e verificação de namespace.__path___ identificou rapidamente o culpado pacote borked no teste.) Misturar pacotes instalados corretamente com pip e puro setup.py develop 'd os de origem (evitando pip) parecem, no entanto, funcionar.

Nós também parecemos ser capazes de entrar em situações estranhas onde um único pacote que contribui com o espaço de nomes pode ser instalado de três maneiras diferentes, às vezes todas simultaneamente. (Chamadas repetidas para pip uninstall , cada uma encontrando mais arquivos, é tão hilário quanto lamentável.) A instalação de dependência ao usar pip install -e parece ser inconsistente também. Na maioria dos casos, acabamos com namespaces devidamente descompactados (instalados), arquivos pth-link (instalados editáveis) e, em um caso, de alguma forma conseguimos obter um .egg compactado instalado, apesar de zip_safe sendo False naquele pacote dependente e nenhuma distribuição .egg sendo fornecida no Pypi.

A frustração com os problemas de namespace atinge o pico após a quarta vez em que um ambiente virtual é destruído para reiniciar do zero. ;)

Não é solução, mas acabei de colocar algumas notas. Ao misturar entre pacotes 'editáveis', pacotes com namespace e pacotes normais, tenho mais sorte com buildout + mr.developer.

Embora o hack de correção @lelit mencionado pareça funcionar para alguns pacotes, ele também quebra alguns pacotes / compilações para nós.

Depois de brincar com a instalação do pip e o modo editável, tive a mesma ideia de @carljm (adicionando um arquivo -nspkg.pth para cada pacote editável), mas ninguém parece ter implementado isso (ou foi agora obsoleto - opção -egg?).

Isso ainda é um problema nas versões mais recentes do python com PEP420 implementado? (leia: ajudaria mudar para uma versão mais recente do python?)

Usar o estilo PEP420 efetivamente me ajudou várias vezes a escrever o modo editável.

Infelizmente, ele vem com suas próprias falhas: por exemplo, find_packages setuptools não oferece suporte , portanto, meus pacotes mais recentes contêm o seguinte hack:

-    packages=find_packages('src'),
+    packages=['toplevel.child.' + package
+              for package in find_packages('src/toplevel/child/')],

ninguém parece ter implementado a adição de um -nspkg.pth para cada pacote editável.

Verifique Setuptools 31, que adiciona suporte para esse recurso e também coexiste com pacotes PEP-420 em Python 3.5+.

Para qualquer pessoa curiosa, aqui está uma lista exaustiva de como os pacotes de namespace funcionam em pip install , pip install -e , python setup.py install e python setup.py develop :

https://github.com/jonparrott/namespace-pkg-tests/blob/master/table.md

tl; dr: Você pode usar pip install -e e python setup.py develop , desde que todos os outros pacotes em seu namespace tenham sido instalados usando pip .

Vou encerrar este problema. Parece que o setuptools 31 corrigiu isso para nossos scripts de reprodução e, além disso, não há nada que o pip possa fazer aqui.

@jonparrott
Quais versões de pip e setuptools foram usadas para obter resultados em https://github.com/jonparrott/namespace-pkg-tests/blob/master/table.md ?

@dstufft Embora eu aprecie que esteja supostamente corrigido, gostaria de ver a tabela de compatibilidade de @jonparrott novamente executada como prova. Espero o melhor, planeje o pior para os tickets que têm quase 7 anos e têm cenários de falha com escopo tão amplo. A confiança não é alta devido ao extenso histórico deste problema, e reexecutar a suíte nox por conta própria, as falhas indicariam uma falta de resolução real.

Nos exemplos de @jonparrott , os casos de falha podem ser destilados até "usando python setup.py install diretamente (excluindo as falhas PEP 420 no Python 2, que são esperadas). Isso está falhando mesmo em casos onde o pip não está envolvido em tudo (como python setup.py install + python setup.py develop ).

Este tíquete era para combinações de pip install . e pip install -e ou python setup.py develop .

O gráfico já postado por @jonparrott confirma que este tíquete foi resolvido e qualquer problema remanescente aqui é um problema com python setup.py install e não com pip.

Acabei de executar meus testes novamente e tudo está igual ao que eu executei inicialmente. Eu concordo com a avaliação de @dstufft - pip fez tudo o que pode para resolver isso.

@ piotr-dobrogost o teste usa as versões mais recentes de ambos. No momento desta escrita, pip 9.0.1 e setuptools 34.3.2.