<p>pip 19.0 falha ao instalar pacotes que importam pacote a ser instalado do CWD</p>

Este parece ser um problema com a forma como o pyinstaller se importa para a instalação.

Pode ser uma boa ideia registrar um problema no pessoal do PyInstaller.

Atualmente usamos 18.1 e atualizar para 19.0 causa esse problema para nós também. Há um problema relacionado no repositório PyInstaller, onde é porque pip '' não está em sys.path.

https://github.com/pyinstaller/pyinstaller/issues/2730

Acho que este é um fluxo de trabalho bastante comum. Você coloca __version__ = "1.2.3" em foo/__init__.py e, em seguida, faz import foo em setup.py para que não tenha que especificar a versão em dois lugares. E qualquer usuário da biblioteca pode inspecionar a versão de acordo com PEP 396 .

# foo/__init__.py
__version__ = "1.2.3"

# setup.py
from setuptools import setup

import foo

setup(..., version=foo.__version__)

Além disso, isso só acontece se você tiver um arquivo pyproject.toml (e setup.py ). Remova-o e a instalação funcionará bem. Portanto, parece haver algumas diferenças de comportamento nisso. Talvez a forma tradicional modifique sys.path / PYTHONPATH ?

Ah, acho que entendi o que está acontecendo. Já que ao usar um arquivo pyproject.toml , você está basicamente dizendo ao pip que deseja usar o PEP 517/518.

# pyproject.toml
[build-system]
requires = ["setuptools", "wheel"]

O acima informa ao pip que ele precisa de setuptools e wheel para construir o PyInstaller. Mas no caso do PyInstaller, ele também tem isso em seu setup.py :

# setup.py
from PyInstaller import __version__

De uma perspectiva PEP 517, além de setuptools e wheel , isso significa que ele precisa ser construído. O que, claro, é um pouco estranho.

# pyproject.toml
[build-system]
requires = ["setuptools", "wheel", "PyInstaller"]

Como @cjerdonek mencionado em https://github.com/pypa/pip/issues/6175#issuecomment -456769285, alguém poderia verificar se --no-use-pep517 corrige isso para eles?

Suspeito que a causa desse problema seja o isolamento de compilação ou o código PEP 517 não garantindo que a raiz do diretório do pacote esteja no sys.path, porque o pandas tem um versioneer.py próximo ao setup.py. Lembro-me disso surgindo em algum momento, mas não me lembro de cara o que foi essa discussão. Isso pode ser considerado um problema com o back-end de compilação do setuptools em vez do pip, ou pode ser a falha do mecanismo de isolamento do pip.

[...] Alguém poderia verificar se --no-use-pep517 corrige isso para eles?

O PyInstaller pode ser instalado corretamente com --no-use-pep517 .

Ok, então isso certamente é um problema com o novo código PEP 517 e tenho certeza que o problema é apenas que o diretório que contém a raiz do projeto não foi adicionado a sys.path . Talvez @pfmoore tenha uma ideia melhor se isso deveria ser responsabilidade de pip ou ferramentas de configuração.

Se ajudar, outro exemplo disso (via apache-airflow é pip install pendulum==1.4.4 falha, mas pip install --no-use-pep517 pendulum==1.4.4 funciona.

O rastreamento de pilha que obtemos é semelhante:

Collecting pendulum==1.4.4
  Using cached https://files.pythonhosted.org/packages/85/a5/9fc15751f9725923b170ad37d6c61031fc9e941bafd5288ca6ee51233284/pendulum-1.4.4.tar.gz
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  Complete output from command /Users/ash/.virtualenvs/clean-airflow/bin/python3.7 /Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/tmprosed3kj:
  Traceback (most recent call last):
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 207, in <module>
      main()
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 197, in main
      json_out['return_val'] = hook(**hook_input['kwargs'])
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 54, in get_requires_for_build_wheel
      return hook(config_settings)
    File "/private/var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/pip-build-env-g__m0jh6/overlay/lib/python3.7/site-packages/setuptools/build_meta.py", line 115, in get_requires_for_build_wheel
      return _get_build_requires(config_settings, requirements=['wheel'])
    File "/private/var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/pip-build-env-g__m0jh6/overlay/lib/python3.7/site-packages/setuptools/build_meta.py", line 101, in _get_build_requires
      _run_setup()
    File "/private/var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/pip-build-env-g__m0jh6/overlay/lib/python3.7/site-packages/setuptools/build_meta.py", line 85, in _run_setup
      exec(compile(code, __file__, 'exec'), locals())
    File "setup.py", line 47, in <module>
      from build import *
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/build.py", line 7, in <module>
      from pip._vendor import pytoml
  ModuleNotFoundError: No module named 'pip'

Além disso, a instalação do seguinte também não funciona com o pip v 19.0, mas funcionaria se o --no-use-pep5517 fosse usado:
pendulum == 1.5.0 (AttributeError: módulo 'enum' não tem atributo 'IntFlag')
pendulum == 1.5.1 (AttributeError: módulo 'enum' não tem atributo 'IntFlag')
pendulum == 2.0.0 (AttributeError: módulo 'enum' não tem atributo 'IntFlag')
pendulum == 2.0.1 (AttributeError: módulo 'enum' não tem atributo 'IntFlag')
pendulum == 2.0.2 (AttributeError: módulo 'enum' não tem atributo 'IntFlag')

Considerando que 2.0.3 e 2.0.4 instalam bem.

cartopy (pelo menos sua versão mais recente) também falha ao instalar desde 19.0, não ao importar seu versioneer.py que está próximo a setup.py

Este também é um problema com alguns projetos com os quais eu lido. Usamos um pyproject.toml para definir nossos parâmetros de python black e fazemos um from project.version import __version__ semelhante em nosso setup.py.

No mínimo, eu sinto que não seria suficiente definir nenhum isolamento de projeto no pyproject.toml. Não me parece razoável fazer qualquer pessoa que queira instalar o projeto usar --no-buid-isolation ou --no-use-pep517

A falha parece estar em get_requires_for_build_wheel , e o backend do setuptools executa setup.py para fazer algum tipo de introspecção para determinar os requisitos de construção (o código específico está aqui ). Esse código parece estranho para mim e não entendo por que é necessário. Meu instinto inicial é que esse é um bug no back-end do setuptools que deve ser corrigido por eles.

O PEP 517 não afirma que os front-ends devem executar ganchos em um ambiente que adiciona o diretório de construção a sys.path , e há uma preocupação potencial de que, se fizéssemos isso, poderia quebrar o isolamento (se o diretório de construção contivesse uma cópia de algum pacote necessário, mas não especificado, por exemplo). Portanto, minha preferência seria não adicionar o diretório de construção a sys.path . Mas pode ser conveniente fazer isso se isso oferecer uma solução rápida para essa regressão. Não acho que os projetos devam depender disso, no entanto.

Resumo:

1. Isso deve ser relatado às ferramentas de configuração para revisão como um problema de back-end. Eu consideraria consertá-lo no backend do setuptools (possivelmente apenas adicionando o diretório de compilação a sys.path ) como a resolução ideal.
2. Se o setuptools não fizer isso, o pip pode adicionar o diretório de compilação a sys.path , mas não acho que o PEP 517 veja isso como responsabilidade do frontend.
3. Exigir que o diretório de compilação seja visível para os ganchos em sys.path exigiria pelo menos um esclarecimento PEP.

Não creio que este cenário tenha sido considerado quando o PEP 517 estava sendo desenvolvido. Talvez porque seja específico para ferramentas de configuração (ou melhor, específico para back-ends que executam código Python arbitrário como parte da construção).

Eu acho que é bastante comum para as pessoas importar algo do diretório atual para um setup.py , e geralmente tratar as coisas como se setup.py estivesse em $PWD .

Acho que é razoável empurrar essa responsabilidade para setuptools , já que esse é provavelmente o único projeto que realmente precisa dela.

Sim, pensando mais um pouco sobre isso, tenho certeza que é uma responsabilidade do back-end do setuptools. Antes do PEP 517, o pip executava setup.py como um script, portanto, as regras padrão do Python colocam o diretório do script em sys.path . No PEP 517, a invocação de setup.py é substituída por chamadas para os ganchos de back-end, portanto, esses ganchos precisam preservar a semântica. Como o setuptools executa setup.py em processo a partir dos ganchos, ele precisa gerenciar sys.path si. Felizmente, não é uma grande correção para eles. @jeanlaroche (ou outra pessoa com esse problema), você poderia levantar um problema no rastreador de

[...] Alguém poderia verificar se --no-use-pep517 corrige isso para eles?

Posso confirmar que --no-use-pep517 permite que pip install pandas seja bem-sucedido.

Também posso confirmar que usar --no-use-pep517 funciona para todos os meus pacotes quebrados

sucesso para mim também

pip install pyinstaller --no-use-pep517
Collecting pyinstaller
  Using cached https://files.pythonhosted.org/packages/03/32/0e0de593f129bf1d1e77eed562496d154ef4460fd5cecfd78612ef39a0cc/PyInstaller-3.4.tar.gz
Requirement already satisfied: setuptools in c:\python37\lib\site-packages (from pyinstaller) (39.0.1)
Collecting pefile>=2017.8.1 (from pyinstaller)
  Downloading https://files.pythonhosted.org/packages/ed/cc/157f20038a80b6a9988abc06c11a4959be8305a0d33b6d21a134127092d4/pefile-2018.8.8.tar.gz (62kB)
    100% |████████████████████████████████| 71kB 1.0MB/s
Collecting macholib>=1.8 (from pyinstaller)
  Downloading https://files.pythonhosted.org/packages/41/f1/6d23e1c79d68e41eb592338d90a33af813f98f2b04458aaf0b86908da2d8/macholib-1.11-py2.py3-none-any.whl
Collecting altgraph (from pyinstaller)
  Downloading https://files.pythonhosted.org/packages/0a/cc/646187eac4b797069e2e6b736f14cdef85dbe405c9bfc7803ef36e4f62ef/altgraph-0.16.1-py2.py3-none-any.whl
Collecting pywin32-ctypes (from pyinstaller)
  Using cached https://files.pythonhosted.org/packages/9e/4b/3ab2720f1fa4b4bc924ef1932b842edf10007e4547ea8157b0b9fc78599a/pywin32_ctypes-0.2.0-py2.py3-none-any.whl
Collecting future (from pefile>=2017.8.1->pyinstaller)
  Downloading https://files.pythonhosted.org/packages/90/52/e20466b85000a181e1e144fd8305caf2cf475e2f9674e797b222f8105f5f/future-0.17.1.tar.gz (829kB)
    100% |████████████████████████████████| 829kB 1.6MB/s
Installing collected packages: future, pefile, altgraph, macholib, pywin32-ctypes, pyinstaller
  Running setup.py install for future ... done
  Running setup.py install for pefile ... done
  Running setup.py install for pyinstaller ... done
Successfully installed altgraph-0.16.1 future-0.17.1 macholib-1.11 pefile-2018.8.8 pyinstaller-3.4 pywin32-ctypes-0.2.0

Não acho que seja um bug no pip / setuptools, pela minha leitura da seção Build Environment do pyproject.toml estão disponíveis.

Também importar o pacote que está sendo instalado de setup.py é uma prática ruim? Existem maneiras muito melhores de manter a versão do pacote em um só lugar, por exemplo, conforme descrito neste guia de embalagem do PyPA.

Na discussão em pypa / setuptools # 1642, @uranusjr e eu esperávamos que esta pudesse ser uma oportunidade para fazer as pessoas pararem de confiar no fato de que . está em sys.path quando você executa um script python e comece a mover as pessoas para uma semântica mais explícita.

O maior problema aqui é que a mera presença de pyproject.toml está optando por pessoas no PEP 518 e PEP 517, então mesmo que você não tenha especificado um back-end de construção, de repente está recebendo a nova semântica.

Esta decisão da parte de pip é irreversível neste ponto? Talvez possamos ter a presença de pyproject.toml optando por você no PEP 518, mas o PEP 517 não é acionado a menos que você realmente especifique um back-end de construção?

Honestamente, é uma situação difícil, mas acho que é mais fácil para pip avisar sobre isso do que para setuptools . Se aceitarmos o PEP 517 por enquanto e dissermos que a existência de pyproject.toml começará a acionar o PEP 517 após 20.0 ou 21.0, podemos criar um guia de migração e começar a emitir avisos em pip para esse efeito - " build-backend ausente em pyproject.toml , esteja ciente de que após a versão 21.0, o isolamento de compilação usará setuptools.build_meta padrão, consulte o guia de migração em ..."

Também importar o pacote que está sendo instalado de setup.py é uma prática ruim? Existem maneiras muito melhores de manter a versão do pacote em um só lugar, por exemplo, conforme descrito neste guia de embalagem do PyPA.

Para ser justo, esse guia define a importação do pacote que está sendo instalado de setup.py como a estratégia 6, então é definitivamente algo comum. Nesse ponto, se estamos nos afastando desse tipo de estratégia, essa página deve ser atualizada para não incluí-la mais.

A decisão de acionar o PEP 517 sobre a existência de pyproject.toml foi uma escolha deliberada (a discussão provavelmente foi sobre o problema de implementação do PEP 517 ou o PR, mas não tenho tempo agora para localizá-lo). Obviamente, isso poderia ser alterado à luz do que vemos aqui, mas não devemos fazer isso sem a devida consideração das razões pelas quais tomamos a decisão que tomamos.

O próprio Pip não tem (não deveria, IMO) avaliar se setup.py está certo em assumir que o diretório do projeto está em sys.path , então estou relutante em mudar o pip simplesmente porque o setuptools deseja enviar um padrão diferente quando o back-end for usado. Embora eu concorde que importar o projeto que está sendo construído em setup.py tenha uma série de dificuldades, não é como se fosse algo que disparou avisos até agora, então presumi que o back-end deveria manter essa semântica. Colocando de outra forma, mesmo se pip avisou como você sugeriu, por que os usuários leriam "o isolamento de compilação usará setuptools.build_meta padrão" como significando "você não poderá importar seu projeto de setup.py "? Os dois fatos parecem não ter relação com mim ...

Pessoalmente, concordo com a abordagem atual de confiar na existência do arquivo pyproject.toml. Os problemas da IMO decorrem de pessoas que usam pyproject.toml para outras coisas além de empacotamento. A saída correta é, portanto, empurrar ferramentas sem empacotamento para oferecer outra maneira de configuração, para que as pessoas possam escolher se querem usar pyproject.toml ou não.

O próprio Pip não tem (não deveria, IMO) avaliar se setup.py está certo em assumir que o diretório do projeto está em sys.path, então estou um tanto relutante em mudar o pip simplesmente porque o setuptools quer enviar um padrão diferente quando o back-end é usado.

Verdade, é que pip está fazendo a suposição de que invocar os ganchos setuptools.build_meta é e deve ser perfeitamente equivalente a chamar setup.py . Já vimos casos em que não é, e acho que ainda não foi estabelecido se nós ( setuptools ) queremos que o contrato de setuptools.build_meta seja "isso é equivalente a chamar python setup.py "ou se quisermos que seja" esta é uma versão mais fechada e isolada de invocar setup.py diretamente ".

Claro que setuptools poderia dizer "esse não é o contrato da função, então não vamos corrigi-lo" e pip poderia dizer, "nossa decisão foi que o padrão é PEP 517" e ambos podemos dizer que o bug está em outro projeto, mas provavelmente é uma boa ideia coordenar.

Colocando de outra forma, mesmo se pip avisou como você sugeriu, por que os usuários leriam "o isolamento de construção será padronizado para usar setuptools.build_meta", implicando "você não será capaz de importar seu projeto de setup.py"? Os dois fatos parecem não ter relação com mim ...

Eles podem ou não estar relacionados, mas também pode haver outras alterações na semântica. O objetivo de um aviso como esse é dizer: "Por favor, seja explícito sobre como você deseja que essa construção aconteça, porque em breve iremos incluir você em algo que pode quebrar sua construção." Os projetos podem adicionar o back-end de construção a seus pyproject.toml antecedência e corrigir proativamente quaisquer quebras que possam ocorrer.

Também poderíamos criar um back-end PEP 517 "fictício" em setuptools como setuptools.build_meta_legacy que apenas chdir s no diretório raiz e invocar setuptools.build_meta , dessa forma as pessoas podem optar pelo antigo comportamento apenas se precisarem antes de começar a quebrar.

Pessoalmente, concordo com a abordagem atual de confiar na existência do arquivo pyproject.toml. Os problemas da IMO decorrem de pessoas que usam pyproject.toml para outras coisas além de empacotamento.

Acho que precisamos separar o PEP 517 do PEP 518. O PEP 518 lista explicitamente quais são os "valores padrão" do PEP, enquanto o PEP 517 não especifica nada sobre o que é o back-end padrão.

Eu me lembro de não me sentir terrivelmente avesso a toda "a existência de pyproject.toml permite que você construa o isolamento", mas vendo isso na prática, também não gosto da ideia de que especificar as dependências de minha construção isolada também seria uma opção eu em setuptools.build_meta .

Talvez a solução seja dividir a diferença e ter o padrão de back-end em setuptools.build_meta_legacy (que tenta manter a semântica de setup.py ). Dessa forma, teremos pelo menos uma maneira de saber se um usuário fez uma escolha afirmativa para usar a nova semântica ou se simplesmente não pensou sobre isso.

Um build_meta_legacy com uma mensagem de aviso parece uma solução razoável para mim. É provavelmente melhor deixar o aviso bem visível (por exemplo, durante a instalação e encorajar os usuários a arquivar isso como um bug para o mantenedor), com instruções claras sobre como a migração deve ser feita.

Devo também observar a intenção do pip (que é o pip "corporativo" ;-) - o que quero dizer é que os desenvolvedores do pip discutiram isso um pouco e chegaram a um consenso geral de que parecia uma ideia razoável, mas ainda não é um plano firme e depende de alguém realmente escrever o código para que isso aconteça) é que mudamos de forma relativamente rápida para passar todos os projetos pelo PEP 517 e abandonar nosso caminho de código legado por setup.py completamente Tornar o backend das ferramentas de configuração apenas no pip 21.0 (para usar a versão sugerida acima) empurra isso para pelo menos mais 2 anos.

enquanto o PEP 517 não especifica nada sobre qual é o back-end padrão

Verdadeiro. Mas em algum ponto, o pip vai abandonar o suporte de caso especial de setuptools. Afinal, esse é o objetivo (para nós, pelo menos) do PEP 517, de separar o front-end do back-end e colocar todos os back-ends em pé de igualdade. Portanto, sempre que fizermos isso, teremos que errar se não houver back-end ou escolher um padrão (e iremos padronizar as ferramentas de configuração, por motivos de legado). O debate aqui é quando fazemos isso, não se.

Pip atualmente tem 2 caminhos de código para instalações - o caminho PEP 517 e o caminho setup.py legado. Essa é uma fonte de problemas de manutenção e possíveis bugs. Optamos por tornar o PEP 517 o padrão se pyproject.toml estivesse presente para garantir o uso do caminho PEP 517 (é improvável que os projetos se apressem em adicionar build-backend = setuptools.buid_meta , portanto, sem o comportamento atual, as chances são de que o teste do código PEP 517 do pip e do back-end do setuptools permaneceria próximo de zero por um longo período). Há um opt-out na forma de --no-use-pep517 precisamente para atender aos casos (raros assumidos) em que o back-end das ferramentas de configuração não era adequado.

Eu não acho que alguém previu que as ferramentas de configuração gostariam de ter diferenças semânticas entre setup.py e o back-end, então a possibilidade de --no-use-pep517 ser necessária para contornar as diferenças semânticas com tanta frequência que deveria ser o padrão nunca foi considerado.

Também poderíamos criar um back-end PEP 517 "fictício" em ferramentas de configuração como setuptools.build_meta_legacy que apenas chdirs no diretório raiz e invoca setuptools.build_meta, dessa forma as pessoas podem optar pelo comportamento antigo apenas se precisarem antes de começar a quebrar .

Essa pode ser uma solução razoável. Mas teria que ser pelo menos parcialmente documentado - no mínimo, pip documentaria que esse era o valor padrão que assumiríamos. Se o setuptools optou por deixar o backend sem documentação, é a escolha deles, eu acho.

Não tenho certeza de quão útil qualquer outra discussão teórica é. Certamente não tenho mais nada a acrescentar. Eu sugeriria que, se alguém quiser levar isso adiante, a melhor maneira seria criar um PR mudando o padrão e discutir se queremos aceitá-lo.

Para mantenedores de pacotes que procuram resolver esse problema para seus usuários: Publiquei um shim que implementa a correção sys.path .

https://pypi.org/project/setuptools-localimport/

Esperançosamente, isso pode funcionar como um paliativo para que possamos ponderar como isso deve ser levado adiante sem apressar-se em uma solução, ou retardar desnecessariamente a adoção do pip 19.0 (que contém muito mais guloseimas do que apenas PEP 517).

Publiquei um shim que implementa a correção sys.path.

Fantástico! Independentemente da correção final, este é um exemplo muito bom da flexibilidade do sistema de gancho PEP 517 :-)

Eu consertei fazendo downgrade da minha versão do pip abaixo de 19.x, então tentei instalar e fui bem-sucedido

Há um terceiro caso de uso: e os pacotes que fornecem seu próprio back-end de construção? Por exemplo: o próprio setuptools lista wheel como um requisito de compilação:

[build-system]
requires = ["wheel"]
build-backend = "setuptools.build_meta"

Isso obviamente irá falhar se o código de pip para lidar com PEP 517 não adicionar o diretório de origem a sys.path .

Do PEP 517:

Ao importar o caminho do módulo, não procuramos no diretório que contém a árvore de origem, a menos que esteja em sys.path de qualquer maneira (por exemplo, porque é especificado em PYTHONPATH). Embora o Python adicione automaticamente o diretório de trabalho ao sys.path em algumas situações, o código para resolver o back-end não deve ser afetado por isso.

Isso muito claramente (para mim) diz que os projetos não devem esperar ver seu próprio diretório de projeto ao resolver build-backend - portanto, o setuptools precisa ser adicionado a requires IMO. E sim, eu entendo que fazer isso é circular. Mas back-ends de construção que se constroem sozinhos são, por natureza, bastante circulares - certamente não são o caso normal.

Essa mesma seção também me parece confirmar que as ferramentas de construção não devem esperar que o diretório do projeto esteja no sys.path do ambiente de construção.

Como isso funcionaria com --no-binary :all: ?

@pfmoore Uma variante da situação é que um pacote fornece um sistema de construção personalizado. O sistema de compilação não está instalado (e não faz parte do bdist), mas é fornecido com o sdist, talvez para personalizar algum processo de compilação. Este é um caso de uso válido ou o mantenedor deve publicar o sistema de compilação personalizado como um pacote separado?

Editar: algo como

project/
    custom_build.py
    src/
        my_package/
            __init__.py
            ...
    pyproject.toml  

[build-system]
requires = []
build-backend = "custom_build"

# Maybe the custom backend specifies metadata like this…
[tool.custom_build.metadata]
name = "my-package"
dependencies = []
packages = ["my_package"]

Talvez uma solução seria adicionar uma nova configuração opcional, para indicar onde encontrar os módulos durante a compilação?

[build-system]
requires = []
build-backend = "custom_build"
build-backend-findpath = ["build_systems"]   # Put custom_build.py above in a subdirectory.

O padrão de configuração é [] (lista vazia), o que significa que nenhum caminho é adicionado (ou seja, o mesmo que o comportamento atual), mas os projetos podem adicionar caminhos para encontrar o sistema de construção localmente.

Se build-system for totalmente omitido, o padrão da seção é:

requires = ["setuptools", "wheel"]
build-backend = "setuptools.build_meta"
build-backend-findpath = [""]

pip pode exibir uma mensagem de aviso / informação para dizer ao usuário para migrar (com um link para uma página de documentação, provavelmente).

Um benefício adicional dessa solução é que tudo pode ser feito no pip (o módulo pep517 vendido, na verdade). Nada precisa ser alterado nas ferramentas de configuração ou nos projetos corrompidos existentes.

Uma variante da situação é que um pacote fornece um sistema de construção personalizado.

Sinceramente não sei. Não é uma situação que pensei sobre mim. Não sei se os autores do PEP o consideraram - não me lembro de nenhuma discussão sobre o assunto quando o PEP estava sendo desenvolvido.

Na verdade, tendo verificado, o PEP 517 diz explicitamente (na seção sobre build-backend ) "Ao importar o caminho do módulo, não procuramos no diretório que contém a árvore de origem, a menos que esteja em sys.path de qualquer maneira "o que implica para mim que é explicitamente desencorajado ter back-ends na árvore. Se alguém poderia contornar isso com código suficientemente tortuoso, não tenho certeza (mas suspeito que não).

O caso de uso esperado quando desenvolvemos o PEP 517 era que os back-ends seriam enviados como rodas no PyPI (ou um índice personalizado), que seria baixado e instalado no ambiente de construção. Como back-ends foram construídos estava explicitamente fora do escopo - minha presunção pessoal era que eles não usariam os mecanismos PEP 517, mas sim um comando de nível inferior ( setup.py bdist_wheel ou flit build , por exemplo ) Usar recursivamente um back-end PEP 517 para construir a si mesmo parecia um passo muito complexo. Foi considerado como parte da implementação do PEP 518 no pip (há uma potencial exploração de fork bomb se um back-end for enviado como um sdist e se usar para construir a si mesmo, que tivemos que prevenir antes mesmo de podermos suportar back-ends não distribuídos como rodas ), mas apenas no contexto de download do back-end do PyPI.

tl; dr; Tudo o que posso oferecer é minhas lembranças das discussões da época - talvez você esteja procurando melhor nos arquivos o histórico real.

Não sei se os autores do PEP o consideraram - não me lembro de nenhuma discussão sobre o assunto quando o PEP estava sendo desenvolvido.

Acabei de começar a olhar os arquivos e parece que essa questão foi de fato discutida em detalhes no final do processo (ou pelo menos bem no início). Não sei qual site é melhor para visualizar os arquivos, mas aqui está um ponto em que a discussão começa a falar sobre essa questão novamente (28 de julho de 2017):
https://mail.python.org/pipermail/distutils-sig/2017-July/031109.html
https://www.mail-archive.com/[email protected]/msg26624.html

Por exemplo, este e-mail específico termina com--

Considerando os muitos problemas que já estamos tendo com o PEP 517, pode fazer mais sentido ter o PEP 517 apenas determinando que o diretório não esteja em sys.path e fazer um pequeno PEP de acompanhamento apenas para python-path.

Informarei se descobrir qual foi o veredicto final, mas incentivo os outros a lerem por si próprios.

Agradável! Obrigado por descobrir isso :-)

Então eu dei uma olhada em um monte de e-mails e acho que você pode pelo menos pular para 29 de agosto, onde Nick parece estar sugerindo que há um consenso em deixar o diretório de origem _out_ de sys.path:
https://mail.python.org/pipermail/distutils-sig/2017-August/031413.html
(Uma por uma, as pessoas estavam se convencendo dos argumentos de Nathaniel.)

No entanto, neste mesmo e-mail com link acima, Nick diz o seguinte :)

1. Se omitir isso for realmente um problema, provavelmente descobriremos em breve, como parte da implementação de um backend setup.py

Aqui está um parágrafo mais completo do e-mail:

Portanto, acho que podemos considerar isso resolvido em favor de "Os front-ends devem garantir que o diretório atual NÃO esteja no sys.path antes de importar o back-end designado", pois começar por aí significará que maximizaremos nossas chances de aprender algo novo como parte do inicial implementação da API provisoriamente aceita.

Não sei ainda se há e-mails posteriores que alteram este resumo, mas não há muitos e-mails sobre o assunto depois.

Obrigado por vasculhar os arquivos para nós, @cjerdonek. Declarando meu entendimento atual do problema:

1. muitos arquivos setup.py do mundo real atualmente assumem que o diretório atual está em sys.path quando são executados, criando problemas de inicialização estranhos, pois os projetos se tratam como uma dependência no momento da instalação
2. O PEP 517 diz explicitamente que os front- ends de construção não devem adicionar implicitamente o diretório atual a sys.path (não diz nada sobre back-ends)
3. pip 19.0 considera pyproject.toml sem uma seção build-system equivalente a uma seção build-system que especifica o setuptools backend
4. o back-end setuptools PEP 517 também não adiciona o diretório atual a sys.path (já que se afastar do ponto 1 acima é considerado um objetivo futuro desejável)
5. Duas soluções temporárias estão disponíveis para projetos existentes enquanto os comportamentos padrão são aprimorados: fixar pip em menos de 19,0 e definir explicitamente a opção --no-use-pep517 . No entanto, as pessoas só os descobrem após descobrirem que atualizar pip quebra suas compilações.

De uma perspectiva funcional, acho que a principal mudança que queremos introduzir é que no caso " pyproject.toml sem uma build-system section", o diretório contendo setup.py deve terminar em sys.path novamente. Existem duas maneiras principais de lidar com isso:

1. Obtenha pip para fazer isso. Isso tem o infeliz efeito colateral de tornar o comportamento dependente do front-end e, portanto, potencialmente ver projetos existentes falharem na instalação, a menos que todos os front-ends implementem a mesma solução alternativa
2. Obtenha o back-end de setuptools PEP 517 para fazer isso, inspecionando pyproject.toml para uma seção build-system e injetando o diretório setup.py em sys.path se a seção e a entrada do caminho estiverem ausentes. Um novo pip ainda é necessário nessa situação, uma vez que deve especificar uma versão mínima de ferramentas de instalação que trate corretamente o caso "não build-system section".

No interesse de fazer com que as coisas funcionem para os usuários finais o mais rápido possível, sem nos colocarmos em qualquer canto de design infeliz, eu realmente proponho uma resolução de 3 etapas:

1. Faça uma nova versão pip (19.0.1?) Agora que adiciona a entrada sys.path extra para o caso "no build-system entry". Nesse ponto, o problema de compatibilidade deve desaparecer amplamente para os usuários finais.
2. Faça uma nova versão setuptools que lida com a adição de sys.path se o front end ainda não tiver feito isso.
3. Em uma versão posterior de pip , altere o caso "no build-system entry" para eliminar a caixa especial e, em vez disso, defina uma versão mínima mais restrita para setuptools .

Esta proposta é baseada no fato de que acho que o back-end de setuptools PEP 517 é o lugar "certo" para lidar com setup.py problemas de compatibilidade com versões anteriores, mas também acho que ajustar pip diretamente provavelmente será uma mudança muito mais simples no curto prazo, e é uma mudança que conterá o problema enquanto a correção mais arquiteturalmente preferível é trabalhada.

Criei o back-end build_meta_legacy em pypa / setuptools # 1652. Eu realmente preferiria que pip passasse a usar setuptools.build_meta_legacy como back-end padrão, mas acho que criar um back-end "legado" integrado é o máximo que estou confortável para fazer em setuptools . Não quero ficar preso indefinidamente no suporte à "emulação python setup.py install " completa no back-end principal de setuptools PEP 517.

Estou um pouco confuso porque o setuptools não deseja emular a execução do script nativamente aqui TBH. Parece que ele está pedindo para os usuários finais ficarem confusos quando python setup.py bdist_wheel funciona corretamente, mas pip wheel não (assumindo que eles tenham definido o back-end de compilação não legado).

Qual é o motivo?

Qual é o motivo?

Meu plano de longo prazo é descontinuar toda invocação direta de setup.py em favor da invocação indireta por qualquer front-end PEP 517 ou algo equivalente (para outros comandos). Se estamos mudando para um mundo de "todos os ambientes isolados", não quero ser forçado a manter a semântica de setuptools invocações de comando compatível com a invocação de python setup.py , pelo mesmo motivo PEP 517 disse especificamente que front-ends não deveriam fazer isso - tem o potencial de quebrar o isolamento do build e geralmente criar situações indesejáveis.

Acho que é bastante raro que isso seja necessário, exceto como parte de um antipadrão. Qualquer pessoa com uma necessidade legítima pode facilmente manipular sys.path em seu script de configuração.

Apenas como uma observação, não acho que o PEP 517 jamais teve como objetivo de design que todo o acesso às ferramentas de construção fosse possível através dos ganchos. Por exemplo, flit tem seu próprio conjunto de comandos flit build etc, e não há nenhuma intenção que eu saiba de descontinuá-los. Portanto, é possível encontrar casos extremos em que a intenção por trás do PEP 517 era que comandos específicos de ferramentas precisassem ser usados. Um exemplo óbvio é construir o próprio back-end (como mencionei acima), mas existem outros casos (não padronizados atualmente, embora PEPs futuros possam adicionar ganchos), como instalações editáveis ​​e compilações no local (reutilizando artefatos de compilações anteriores).

Chegar a um acordo de que todas as ferramentas poderiam suportar "build sdist" e "build wheel" foi difícil o suficiente para que eu não preveja estender a lista de operações padrão em breve.

Apenas como uma observação, não acho que o PEP 517 jamais teve como objetivo de design que todo o acesso às ferramentas de construção fosse possível através dos ganchos.

Não é isso que eu sugeri, e é um pouco uma digressão. Meu ponto era que os problemas que PEP necessitado 518 também existem em geral, para todos os setup.py comandos, e esses são melhor resolvidos movendo as pessoas longe de invocar setup.py em tudo. Nenhum padrão é necessário para fazer isso da mesma maneira que flit não precisa de um PEP para adicionar subcomandos.

Ah ok. Desculpe pelo mal entendido.

A transição proposta por @ncoghlan parece boa para mim. Se ninguém tem problemas com isso, vamos em frente.

Obrigado por desenterrar os arquivos @cjerdonek!

Dado que já existe um PR que corrige isso nas ferramentas de configuração (por meio da introdução do back-end legado). Há algum motivo para não pular a etapa 1 acima? Estamos instalando ferramentas de configuração em um ambiente de construção isolado, portanto, depender de uma versão muito recente não deve ser um problema.

Há algum motivo para não pular a etapa 1 acima?

Não. Podemos alterar diretamente a versão mínima necessária atual.

Meu plano de transição é baseado na suposição de que as pessoas precisarão de mais tempo para trabalhar no mecanismo de transição de longa duração no lado setuptools - enquanto que o backend de transição dedicado de @pganssle parece promissor nesse aspecto, estou não tenho certeza se faz sentido deixar o status quo em vigor enquanto a mudança está sendo revisada.

Dito isso, não estou familiarizado com os detalhes de como funciona a implementação do PEP 517 em pip , portanto, minha suposição de que resolver o problema no front end seria simples pode estar incorreta.

Como os back-ends são executados em um subprocesso (e de fato, usando o projeto pep517 vendido, que adiciona um nível extra de indireção) não é nada óbvio para mim como definiríamos sys.path para um gancho de back-end. No mínimo, precisaríamos envolver PYTHONPATH que significa nos preocupar com os casos em que o usuário já tem PYTHONPATH definido e como o código de isolamento o usa.

Essencialmente, definir sys.path no pip é, eu suspeito, distintamente não trivial. É improvável que eu tenha tempo para examinar os detalhes, muito menos escrever um patch (e garantir que ele seja devidamente testado!) Sozinho.

Acho que obter um back-end de ferramentas de configuração fixo é o caminho mais rápido.

Meu plano de longo prazo é descontinuar todas as invocações diretas de setup.py em favor da invocação indireta por front-ends PEP 517 ou algo equivalente (para outros comandos).

@pganssle ai. setup.py processuais deve morrer. Não deveria existir por nenhum motivo. Porque essa "flexibilidade" é uma fonte inesgotável de dor e colapsos. É impossível migrar setup.py e, portanto, todos os problemas com o empacotamento Python.

Eu substituiria setup.py por package.json e apenas adicionaria a seção Python ao invés de outro formato de descrição de pacote.

Assim, posso usar ==1.x especificadores de versão .

@techtonik Por favor, vá embora. Suas contribuições não construtivas são indesejadas em qualquer projeto do qual eu seja participante.

Trabalhar no # 6210 me permitiu responder minha própria pergunta acima sobre como será difícil resolver isso no nível pip : o desafio é que a informação sobre se o diretório de origem deve ou não ser inserido como sys.path[0] precisa ser tunelado a partir do código que lê pyproject.toml até o chamador do gancho PEP 517 e, em seguida, para o script de wrapper em processo real.

Isso é factível sem grandes mudanças arquitetônicas (um prefixo pip._implicit. no nome do back-end de construção para a primeira parte e um PEP517_SYS_PATH_0 env var para a última), mas significa modificar temporariamente o pep517 vendido setuptools esteja pronta.

Meu plano de transição é baseado na suposição de que as pessoas precisarão de mais tempo para trabalhar no mecanismo de transição de longa duração no lado das ferramentas de embora o backend de transição dedicado do

Sim, eu concordo com isso. Eu sugeri apenas isso em um post do distutils, há duas coisas que eu diria que são importantes:

1. Conseguindo uma solução para os usuários o mais rápido possível
2. Conseguir a transição certa .

Pessoalmente, acho que a coisa certa a fazer é remover a lógica "pyproject.toml's existência opta por você no PEP 517" até que tenhamos a lógica de transição no lugar. Considerando que as alterações em setuptools têm consequências para sua API voltada ao público e em pip isso apenas atrasaria o que se tornou uma alteração incompatível com versões anteriores, faz sentido para mim faça a correção rápida em pip enquanto revisamos o caminho a seguir para setuptools .

Com ambas as abordagens operacionais em minha máquina local, testei os números 6210 e 6212 em relação ao requisito problemático original PyInstaller==3.4 .

• # 6210 funcionou como desejado: https://github.com/pypa/pip/pull/6210#issuecomment -458144828
• # 6212 não está https://github.com/pypa/pip/pull/6212#issuecomment -458148519

Não sei se a falha # 6212 é um problema de configuração de teste ou se realmente há mais um problema no pré-lançamento das ferramentas de configuração, só sei que há mais trabalho de integração a ser feito antes que possamos ter certeza dessa solução enquanto estou confiante no # 6210 agora - a única coisa errada com ele é que é um horrível hack de compatibilidade que não queremos que pip carregue para sempre.

Parece que --no-cache é o responsável pela falha de assert em # 6212. O teste com --cache-dir deu um teste local bem-sucedido: https://github.com/pypa/pip/pull/6212#issuecomment -458166386

(Vou ficar off-line por aproximadamente 18 horas para dormir e trabalhar, então as pessoas devem se sentir à vontade para usar o número 6210 ou o número 6212 que fizer sentido enquanto isso)

Eu atualizei o título para refletir melhor a situação. Obrigado @ncoghlan pelos PRs!

Nota de moderação: também fui em frente e ocultei os comentários não produtivos (e as respostas a eles) como "Off Topic" e farei isso para quaisquer comentários futuros nesse sentido. Se alguém quiser discutir sobre a moderação, registre um novo problema ou envie um ping por e-mail; este tópico não é o lugar certo para trazer à tona quaisquer problemas com moderação que você possa ter.

Eu também fui em frente e marquei isso, para evitar que as pessoas criem duplicatas e para sinalizar claramente que sabemos sobre isso.

Mesmo se fizermos o opt-in do pep517, esta é uma mudança de comportamento que não foi anunciada e, portanto, quebrará as bibliotecas _mesmo que já tenham optado_ (consulte PyInstaller , por exemplo). No caso em que uma biblioteca declara um opt-in para pep517 builds _and_ importa coisas localmente que espera encontrar em sys.path , não há nenhuma suposição sendo feita por pip (porque a biblioteca é explícita), mas a biblioteca é ainda quebrado de repente.

Nesse caso, eu realmente não vejo uma alternativa além de apenas incluir cwd nas ferramentas de configuração, porque isso está quebrado. A menos que a proposta seja dizer às pessoas para voltar e corrigir os lançamentos que cortaram entre pep517 e pip 19, que, se qualquer usuário tiver essas versões estritamente fixadas, podem parar de repente de ser instaláveis, eu realmente sinto que devemos considerar o impacto dessas decisões sobre a experiência do usuário. Com base nesta discussão e nas propostas atuais, algumas dessas bibliotecas não serão instaláveis ​​com novas versões do pip + setuptools usando os padrões, a menos que as compilações pep517 sejam explicitamente desabilitadas.

Isso é muito impactante se você está apenas tentando instalar um pacote com as ferramentas fornecidas pelo python, mas na verdade ele não pode instalar coisas de forma aleatória. Digo isso para desviar o foco dos aspectos técnicos por um momento e do impacto para o usuário final, que pode ficar frustrado com as ferramentas, o ecossistema, as bibliotecas ou a própria linguagem, porque de repente (e sim, apenas sob circunstâncias específicas), coisas que eles podiam instalar perfeitamente agora não podem ser instaladas. Eu realmente acho que devemos fechar essa lacuna em qualquer solução que seja implementada.

Atualmente, usamos uma pilha de falha para lidar com instalações com falha no pipenv e estou adicionando --no-use-pep517 quando disponível para lidar com falhas como resultado dessas alterações. Não tenho certeza se isso será intuitivo para o usuário comum, já que provavelmente nem mesmo está imediatamente claro qual é a causa do problema. Digo isso apenas para apontar que temos uma solução alternativa, mas parece importante tentar preencher essa lacuna para ajudar um pouco os usuários

(editar: também muito obrigado a pganssle, cjerdonek, pfmoore, pradyunsg, ncoghlan e todos os outros que têm dedicado muito tempo e esforço nisso)

O caso de uso esperado quando desenvolvemos o PEP 517 era que os back-ends seriam enviados como rodas no PyPI (ou um índice personalizado), que seria baixado e instalado no ambiente de construção. Como os back-ends foram construídos estava explicitamente fora do escopo - minha presunção pessoal era que eles não usariam os mecanismos PEP 517, mas sim um comando de nível inferior (setup.py bdist_wheel ou flit build, por exemplo). Usar recursivamente um back-end PEP 517 para construir a si mesmo parecia um passo muito complexo. Foi considerado como parte da implementação do PEP 518 no pip (há uma potencial exploração de fork bomb se um back-end for enviado como um sdist e se usar para construir a si mesmo, que tivemos que prevenir antes mesmo de podermos suportar back-ends não distribuídos como rodas ), mas apenas no contexto de download do back-end do PyPI.

Apenas para voltar a este ponto - o novo setuptools.build_meta_legacy padrão resolve o problema de usar PEP 517 para tudo, exceto back-ends PEP 517, que é um problema para setuptools si. Se não resolvermos isso, então como @ benoit-pierre aponta em pypa / setuptools # 1644, não será possível para as pessoas usarem pip install --no-binary :all: para qualquer projeto que dependa de setuptools (ou presumivelmente qualquer provedor de back-end PEP 517).

Devemos discutir isso neste tópico ou criar um novo tópico para discuti-lo?

Devemos discutir isso neste tópico ou criar um novo tópico para discuti-lo?

Eu dividiria isso. Meu sentimento imediato é que o problema é que --no-binary :all: tem consequências inesperadas significativas aqui (semelhante na prática ao impacto de usar essa bandeira na presença de um projeto que apenas distribui rodas, não sdists) e eu gostaria para evitar digressões sobre (por exemplo) a conveniência de usar --no-binary :all: para distrair ainda mais este tópico.

Não acho que consertar o problema com --no-binary :all: back-ends de compilação de construção seja tão crítico quanto este. Se um usuário já estiver especificando --no-binary :all: , ele pode adicionar --no-use-pep517 relativa facilidade.

Novo PR # 6229 que:

1. Implementa a solução provisória sugerida por @pganssle de tornar uma seção build-system em pyproject.toml o requisito inicial para ativar automaticamente o PEP 517 (adiando a opção "qualquer pyproject.toml arquivo" em uma versão posterior)
2. Adiciona 3 casos de teste dedicados cobrindo a importação de um pacote adjacente de setup.py

Vou fechar os outros 2 PRs em favor desse, já que é a correção mínima que deve fazer as coisas funcionarem novamente para os usuários finais e não requer nenhum hack horrível como o # 6210 ou um novo lançamento de ferramentas de configuração como o # 6212

Então, onde fica setuptools.build_meta_legacy ? A proposta agora exige que os projetos que precisam da funcionalidade "importar pacote adjacente" especifiquem explicitamente em pyproject.toml ? Se assim for, eu sugiro fortemente que precisa ser documentado em algum lugar, junto com o fato de que a importação de pacotes adjacentes sem essa especificação está obsoleta e será removida no pip 19.X (precisamos concordar o que é X). Não podemos fazer isso uma depreciação programática (eu não acho), mas esse é mais um motivo para documentá-lo claramente, para que não sejamos acusados ​​(novamente) de remover a funcionalidade sem aviso prévio.

Edit: Mas, caso contrário, obrigado pelo novo PR e resumo.

Edição 2: vejo que você fechou a proposta setuptools.build_meta_legacy . Não tenho certeza se gosto disso, pois nos perde a oportunidade de dizer agora qual é nosso plano de longo prazo, estendendo assim qualquer período de depreciação, como mencionei acima ...

@pfmoore Não, significa que voltar ao comportamento desejado deve ser coberto por um novo problema associado à remoção da solução alternativa # 6163 (provavelmente atualizando para setuptools que fornece setuptools.build_meta_legacy ).

Edit: por enquanto, acabei de reabrir # 6212, mas alterei o título para deixar claro que não acho que devemos esperar que toda a discussão build_meta_legacy seja resolvida antes de corrigir os comandos de instalação que estão falhando.

Minha proposta era, na verdade, que o opt-in para PEP 517 especificava build-system.build-backend não a existência de build-system em absoluto, e que entre agora e o lançamento 19.1, setuptools adicionaria build_meta_legacy e pip o usariam como back-end padrão.

Eu concordo que em 19.1, provavelmente se pip não conseguir encontrar setuptools.build_meta_legacy , ele deve retornar ao caminho do código antigo. Isso nos dará mudanças mínimas de quebra, enquanto optamos pelo número máximo de pessoas.

Na verdade, minha proposta era que o opt-in para PEP 517 especificava build-system.build-backend

... que pode ser resolvido simplesmente definindo use_pep517 = False no caso de fallback (em vez de defini-lo como has_pyproject que é o que fazemos agora.

em 19.1, provavelmente se pip não consegue encontrar setuptools.build_meta_legacy, ele deve voltar para o caminho de código antigo

Não acho que vale a pena fazer isso. Estaremos especificando uma versão de setuptools suficientemente recente para ter certeza de que receberemos o back-end legado, e não há necessidade de considerar a possibilidade de que as ferramentas de configuração removam esse back-end em uma versão futura (ou melhor, se o fizerem, nós simplesmente culpe-os pelos problemas resultantes ;-))

Observação: o padrão use_pep517 = False é o que # 6229 começou, mas causou falhas nos testes PEP 518.

1. O caso " build-system.requires está definido" tem que usar o isolamento de compilação, para que possa instalar as dependências solicitadas sem afetar o ambiente pai. A maneira mais fácil de fazer isso, dada a estrutura de código atual, é definir use_pep517 = True neste caso, então fiz isso e passei o caso de teste novamente.
2. Uma mesa [build-system] ausente indica que pyproject.toml está sendo usada apenas para armazenar configurações na tabela [tools] , de modo que deve resultar em use_pep517 = False para ser uma solução alternativa eficaz para o problema relatado originalmente, portanto, marquei este caso de teste como uma falha esperada.
3. Isso deixa o caso "vazio [build-system] table", que eu acho que pode ser razoavelmente resolvido em qualquer direção. No entanto, como eu não acho que este caso específico vá surgir com muita frequência na prática (por que alguém se daria ao trabalho de adicionar uma mesa build-system sem definir requires ou build-backend ?), Optei por resolvê-lo de uma forma que significasse que o caso de teste PEP 518 previamente definido foi aprovado, em vez de adicionar um segundo marcador de falha esperado.

Para resolver 3 na outra direção, precisaríamos mudar a linha:

use_pep517 = build_system is not None

para ser:

use_pep517 = build_system is not None and build_system.get('requires', None)

Dessa forma, apenas um requer não vazio optaria pelo isolamento de compilação PEP 517 (o que também significaria adicionar um quarto caso de teste, uma vez que os campos build-system.requires vazios e não vazios agora se comportariam de maneira diferente).

Desculpe pela contribuição não convidada aqui, mas não posso deixar de notar que tudo isso parece uma maneira bem elaborada de evitar ter o cwd em sys.path e, no final das contas, deixará coisas quebradas que costumavam funcionar, o que parece bastante perturbador de uma perspectiva UX.

Um número não trivial de usuários e pacotes é afetado por isso. Pelo menos alguns deles têm uma seção [build-system] definida e _também_ contam com o comportamento antigo e, portanto, permanecerão corrompidos para qualquer um que tenha essas versões fixadas.

@techalchemy Sim, a suposição original em pip era que setuptools.build_meta funcionava da mesma maneira a partir de uma perspectiva de sys.path que a invocação direta de setup.py funciona, e essa suposição provou estar incorreto. Assim que uma versão setuptools contendo o back-end setuptools.build_meta_legacy definido em https://github.com/pypa/setuptools/pull/1652 estiver disponível, então # 6212 pode ser concluído, e esse seria o longo resolução de prazo. No entanto, não há ETA atual para tal lançamento, então precisamos continuar explorando pip - resoluções apenas para obter o diretório de origem de volta em sys.path para pacotes que não são explicitamente "PEP 517 nativos "

Em # 6229, implementei a sugestão de @pganssle de simplesmente adiar a adoção de "PEP 517 por padrão", mas parece que isso causa mais problemas do que resolve devido a outra mudança em pip 19: o processamento de build-system.requires agora está vinculado ao processamento de build-system.build-backend , então --no-use-pep517 desativa o PEP 518 também (o que causa falhas no conjunto de testes e também pode causar falhas de instalação no mundo real se a compilação dependências não são pré-instaladas).

Em # 6210, eu, em vez disso, corrijo localmente pep517 para apoiar a injeção de sys.path[0] no subprocesso, efetivamente fazendo a mesma coisa que setuptools.build_meta_legacy deve fazer em um futuro setutpools release. Isso parece se comportar da maneira que queremos - build-system.requires ainda é processado, e o diretório de origem é sys.path[0] quando setup.py é executado. Também é muito semelhante ao que propus em https://discuss.python.org/t/pep-517-backend-bootstrapping/789/29?u=ncoghlan e @takluyver redigiu em https://github.com/ pypa / pep517 / pull / 42 / para lidar com back-ends de autoinicialização de uma forma que seja compatível com --no-binary :all:

Desculpe por ser o AWOL RM. Aconteceram coisas que eu não havia previsto.

Eu obviamente prefiro a correção do lado das ferramentas de instalação para isso, mas # 6210 é legal comigo também - como uma correção de curto prazo.

Eu concordo com @techalchemy e @pradyunsg - acho que a correção do lado do setuptools é a abordagem correta aqui. Embora eu aprecie o trabalho de tentar encontrar uma solução rápida dentro do pip, esse tempo não seria mais bem gasto acelerando um novo lançamento de ferramentas de instalação com _build_meta_legacy ? Eu não tenho observado o que está acontecendo nas ferramentas de instalação, então não estou muito claro porque há um problema com o lançamento de uma correção rápida nas ferramentas de instalação (os ciclos de lançamento das ferramentas de instalação são muito mais rápidos que os do pip).

Estou OK com uma correção de curto prazo do lado do pip, mas gostaria de esclarecer quando podemos esperar uma correção do setuptools.

Olá a todos!

Eu tenho o mesmo problema:

**Collecting pyinstaller==3.4
  Using cached https://files.pythonhosted.org/packages/
a0cc/PyInstaller-3.4.tar.gz
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  Complete output from command "c:\program files (x86)\
gram files (x86)\microsoft visual studio\shared\python3
requires_for_build_wheel C:\Users\ASUS\AppData\Local\Te
  Traceback (most recent call last):
    File "c:\program files (x86)\microsoft visual studi
process.py", line 207, in <module>
      main()
    File "c:\program files (x86)\microsoft visual studi
process.py", line 197, in main
      json_out['return_val'] = hook(**hook_input['kwarg
    File "c:\program files (x86)\microsoft visual studi
process.py", line 54, in get_requires_for_build_wheel
      return hook(config_settings)
    File "C:\Users\ASUS\AppData\Local\Temp\pip-build-en
, line 115, in get_requires_for_build_wheel
      return _get_build_requires(config_settings, requi
    File "C:\Users\ASUS\AppData\Local\Temp\pip-build-en
, line 101, in _get_build_requires
      _run_setup()
    File "C:\Users\ASUS\AppData\Local\Temp\pip-build-en
, line 85, in _run_setup
      exec(compile(code, __file__, 'exec'), locals())
    File "setup.py", line 20, in <module>
      from PyInstaller import __version__ as version, H
  ModuleNotFoundError: No module named 'PyInstaller'**

Alguém sabe se o problema está resolvido? Ou como resolver isso temporariamente?

Obrigado a todos!

@ jce94 , use pip <19 por enquanto.

@altendky obrigado pela info!

Não consegui resolver esse problema com as soluções alternativas sugeridas enquanto trabalhava com pipenv . Congelar pip em 18.1 em Pipfile parece não ter efeito, pois pipenv continua forçando a versão mais recente do pip. Posso definir manualmente o pip para 18.1, mas quando recrio o ambiente virtual pipenv, o Pipenv atualiza para o pip mais recente, não importa o quê ... Alguma recomendação para mantê-lo?

@altendky Infelizmente, usar uma versão predefinida do pip não é possível no momento para os usuários do pipenv (e também para poesia, eu acho). Ambos usam versões mais recentes. Estou supondo que muitas pessoas estão presas a pipelines quebrados por enquanto

O que é ainda mais estranho, não está acontecendo de forma consistente. Eu executei novamente um trabalho do Appveyor, o primeiro passou, o segundo falhou, embora eles sejam estritamente idênticos

No caso de alguém estar se perguntando sobre o cronograma, espero que possamos ter uma correção pronta no final desta semana ou no início da semana que vem e fazer um lançamento de correção de bug subsequente do pip logo depois disso.

A nova versão do setuptools, versão 40.8.0 está agora disponível com o backend build_meta:__legacy__ .

Obrigado! E isso é algo que devemos apontar o PyInstaller para usar? Eles eram
bastante descontente com as mudanças ... Qualquer documentação ou PEP que eu possa apresentar
com eles para apoiar as mudanças?

Na terça-feira, 5 de fevereiro de 2019, 10:24, Paul Ganssle < [email protected] escreveu:

A nova versão do setuptools, versão 40.8.0 está agora disponível com o
build_meta: backend __ legacy__.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/pypa/pip/issues/6163#issuecomment-460747909 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ADtXZjnOfu56IYR6VEKK4yowMg3XdcFEks5vKcxBgaJpZM4aNvmP
.

@AlmogCohen Não, isso não é algo que você deve usar diretamente, é apenas para uso pelos front-ends do PEP 517. A próxima etapa é pip começar a usar build_meta:__legacy__ como seu back-end padrão. Isso não é acionável da perspectiva do usuário final.

Algum ETA na nova versão que integrará a correção?

Em algumas horas. :)

Veja o problema fixado.

pip 19.0.2 foi lançado com uma correção para isso.

Não consigo instalar pyinstaller com a última versão do pip, mesmo quando uso --no-use-pep517

pip install pyinstaller --no-cache-dir --no-use-pep517
Collecting pyinstaller
  Downloading https://files.pythonhosted.org/packages/03/32/0e0de593f129bf1d1e77eed562496d154ef4460fd5cecfd78612ef39a0cc/PyInstaller-3.4.tar.gz (3.5MB)
     |████████████████████████████████| 3.5MB 273kB/s
  Installing build dependencies ... done
    ERROR: Complete output from command python setup.py egg_info:
    ERROR: Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\Raffaele\AppData\Local\Temp\pip-install-5e9w2p2c\pyinstaller\setup.py", line 20, in <module>
        from PyInstaller import __version__ as version, HOMEPATH, PLATFORM
    ModuleNotFoundError: No module named 'PyInstaller'
    ----------------------------------------
ERROR: Command "python setup.py egg_info" failed with error code 1 in C:\Users\Raffaele\AppData\Local\Temp\pip-install-5e9w2p2c\pyinstaller\

Este tópico foi bloqueado automaticamente, pois não houve nenhuma atividade recente após seu encerramento. Abra um novo problema para bugs relacionados.