<p>pip 19.0 no puede instalar paquetes que importan paquetes para instalar desde CWD</p>

Esto parece ser un problema con la forma en que pyinstaller se está importando para la instalación.

Podría ser una buena idea presentar un problema a la gente de PyInstaller.

Actualmente usamos 18.1, y la actualización a 19.0 también nos causa este problema. Hay un problema relacionado en el repositorio de PyInstaller, donde se debe a que pip '' no está en sys.path.

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

Creo que este es un flujo de trabajo bastante común. Pones __version__ = "1.2.3" en foo/__init__.py y luego haces import foo en setup.py para no tener que especificar la versión en dos lugares. Y cualquier usuario de la biblioteca puede inspeccionar la versión según PEP 396 .

# foo/__init__.py
__version__ = "1.2.3"

# setup.py
from setuptools import setup

import foo

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

Además, esto solo sucede si tiene un archivo pyproject.toml (y setup.py ). Quítelo y la instalación funcionará bien. Entonces parece haber algunas diferencias de comportamiento allí. ¿Quizás la forma tradicional modifica sys.path / PYTHONPATH ?

Ah, creo que entiendo lo que está pasando. Dado que al usar un archivo pyproject.toml , básicamente le está diciendo a pip que desea usar PEP 517/518.

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

Lo anterior le dice a pip que necesita setuptools y wheel para construir PyInstaller. Pero en el caso de PyInstaller, también tiene esto en su setup.py :

# setup.py
from PyInstaller import __version__

Desde la perspectiva de PEP 517, además de setuptools y wheel , significa que se necesita para construir. Lo cual, por supuesto, es un poco extraño.

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

Como @cjerdonek mencionó en https://github.com/pypa/pip/issues/6175#issuecomment -456769285, ¿alguien podría verificar si --no-use-pep517 soluciona esto?

Sospecho que la causa de este problema es que el aislamiento de compilación o el código PEP 517 no asegura que la raíz del directorio del paquete esté en sys.path, porque pandas tiene un versioneer.py junto a setup.py. Recuerdo que esto surgió en algún momento, pero no recuerdo de la parte superior de mi cabeza cuál fue esa discusión. Esto podría considerarse un problema con el backend de construcción de setuptools en lugar de pip, o podría ser culpa del mecanismo de aislamiento de pip.

[...] ¿podría alguien comprobar si --no-use-pep517 soluciona esto?

PyInstaller se instala bien con --no-use-pep517 .

Ok, entonces eso es ciertamente un problema con el nuevo código PEP 517 y estoy bastante seguro de que el problema es que el directorio que contiene la raíz del proyecto no se ha agregado a sys.path . Tal vez @pfmoore tenga una mejor idea de si eso debería ser la responsabilidad de pip o las herramientas de configuración.

Si ayuda, otro ejemplo de esto (a través de apache-airflow es pip install pendulum==1.4.4 falla, pero pip install --no-use-pep517 pendulum==1.4.4 funciona.

El seguimiento de la pila que obtenemos es similar:

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'

Además, la instalación de lo siguiente tampoco funciona con pip v 19.0, pero lo haría si se usa --no-use-pep5517:
péndulo == 1.5.0 (AttributeError: el módulo 'enum' no tiene atributo 'IntFlag')
péndulo == 1.5.1 (AttributeError: módulo 'enum' no tiene atributo 'IntFlag')
péndulo == 2.0.0 (AttributeError: módulo 'enum' no tiene atributo 'IntFlag')
péndulo == 2.0.1 (AttributeError: módulo 'enum' no tiene atributo 'IntFlag')
péndulo == 2.0.2 (AttributeError: módulo 'enum' no tiene atributo 'IntFlag')

Mientras que 2.0.3 y 2.0.4 se instalan bien.

cartopy (al menos su última versión) tampoco se instala desde la 19.0, al no poder importar su versión eer.py que está al lado de setup.py

Este también es un problema con algunos proyectos con los que me ocupo. Usamos un pyproject.toml para definir nuestros parámetros de Python Black, y hacemos un from project.version import __version__ similar en nuestro setup.py.

Como mínimo, creo que no sería suficiente poder definir ningún aislamiento de proyecto en pyproject.toml. Me parece irrazonable hacer que cualquiera que quiera instalar el proyecto use --no-buid-isolation o --no-use-pep517

La falla parece estar en get_requires_for_build_wheel , y el backend de setuptools ejecuta setup.py para hacer algún tipo de introspección para determinar los requisitos de compilación (el código específico está aquí ). Ese código me parece extraño y no entiendo por qué es necesario. Mi instinto inicial es que se trata de un error en el backend de setuptools que deberían solucionar.

PEP 517 no establece que las interfaces deban ejecutar hooks en un entorno que agregue el directorio de compilación a sys.path , y existe la preocupación potencial de que si hiciéramos eso, podría romper el aislamiento (si el directorio de compilación contuviera una copia de algunos paquetes obligatorios pero no especificados, por ejemplo). Entonces mi preferencia sería no agregar el directorio de compilación a sys.path . Pero puede ser conveniente hacerlo si eso ofrece una solución rápida para esta regresión. Sin embargo, no creo que los proyectos deban depender de esto.

Resumen:

1. Esto se debe informar a setuptools para su revisión como un problema de backend. Consideraría arreglarlo en el backend de setuptools (posiblemente simplemente agregando el directorio de compilación a sys.path ) como la resolución ideal.
2. Si setuptools no lo hace, pip podría agregar el directorio de compilación a sys.path , pero no creo que PEP 517 lo vea como responsabilidad de la interfaz.
3. Requerir que el directorio de compilación sea visible para los ganchos en sys.path requeriría al menos una aclaración de PEP.

No creo que este escenario se haya tenido en cuenta cuando se estaba desarrollando PEP 517. Tal vez porque es específico de las herramientas de configuración (o más bien, específico de los backends que ejecutan código Python arbitrario como parte de la compilación).

Creo que es bastante común que las personas importen algo del directorio actual a un setup.py y, en general, traten las cosas como si setup.py estuvieran en $PWD .

Creo que es razonable trasladar esta responsabilidad a setuptools , ya que probablemente sea el único proyecto que realmente lo necesita.

Sí, pensando en esto un poco más, estoy seguro de que es una responsabilidad de backend de setuptools. Antes de PEP 517, pip ejecutaba setup.py como un script, por lo que las reglas estándar de Python colocan el directorio del script en sys.path . Bajo PEP 517, la invocación de setup.py se reemplaza con llamadas a los ganchos de backend, por lo que esos ganchos deben preservar la semántica. Debido a que setuptools ejecuta setup.py en proceso desde los ganchos, necesita administrar sys.path mismo. Con suerte, no será una gran solución para ellos. @jeanlaroche (o alguien más con este problema) ¿podría plantear un problema en el rastreador de setuptools, refiriéndose a este hilo?

[...] ¿podría alguien comprobar si --no-use-pep517 soluciona esto?

Puedo confirmar que --no-use-pep517 permite que pip install pandas tenga éxito.

También puedo confirmar que usar --no-use-pep517 funciona para todos mis paquetes rotos

éxito para mí también

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

No creo que esto sea un error en pip / setuptools, por mi lectura de la sección Build Environment de pyproject.toml están disponibles.

Además, ¿no es una mala práctica importar el paquete que se está instalando desde setup.py ? Hay formas mucho mejores de mantener la versión del paquete en un solo lugar, por ejemplo, como se describe en esta guía de empaquetado de PyPA.

En la discusión en pypa / setuptools # 1642, @uranusjr y yo esperábamos que esta pudiera ser una oportunidad para que la gente dejara de confiar en el hecho de que . está en sys.path cuando ejecuta un Python y comience a mover a las personas a una semántica más explícita.

El principal problema aquí es que la mera presencia de pyproject.toml está optando a las personas por PEP 518 y PEP 517, por lo que incluso si no ha especificado un backend de compilación, de repente está obteniendo la nueva semántica.

¿Es esta decisión por parte de pip irreversible en este momento? Tal vez podamos tener la presencia de pyproject.toml que lo habilite para PEP 518, pero PEP 517 no se activa a menos que especifique realmente un backend de compilación.

Honestamente, es una situación difícil, pero creo que es más fácil para pip advertir sobre esto que para setuptools . Si aceptamos PEP 517 por ahora y decimos que la existencia de un pyproject.toml comenzará a activar PEP 517 después de 20.0 o 21.0, podemos crear una guía de migración y comenzar a emitir advertencias en pip a ese efecto - " build-backend falta en pyproject.toml , tenga en cuenta que después de la versión 21.0, el aislamiento de compilación usará de forma predeterminada setuptools.build_meta , consulte la guía de migración en ..."

¿No es una mala práctica importar el paquete que se está instalando desde setup.py ? Hay formas mucho mejores de mantener la versión del paquete en un solo lugar, por ejemplo, como se describe en esta guía de empaquetado de PyPA.

Para ser justos, esa guía define la importación del paquete que se está instalando desde setup.py como estrategia 6, por lo que definitivamente es algo común. En este punto, si nos estamos alejando de ese tipo de estrategia, esa página debería actualizarse para no incluirla más.

La decisión de activar PEP 517 sobre la existencia de pyproject.toml fue una elección deliberada (la discusión fue probablemente sobre el problema de implementación de PEP 517 o el RP, pero no tengo tiempo ahora para localizarlo). Obviamente, podría cambiarse a la luz de lo que vemos aquí, pero no deberíamos hacerlo sin la debida consideración de las razones por las que tomamos la decisión que tomamos.

Pip en sí no (no debería, en mi opinión) ver si setup.py tiene razón al asumir que el directorio del proyecto está en sys.path , por lo que soy algo reacio a cambiar pip simplemente porque setuptools quiere implementar un valor predeterminado diferente cuando se usa el backend. Si bien estoy de acuerdo en que importar el proyecto que se está construyendo en setup.py tiene una serie de dificultades, no es como si fuera algo que haya desencadenado advertencias hasta ahora, así que asumí que el backend debería mantener esa semántica. Para decirlo de otra manera, incluso si pip advirtiera como sugieres, ¿por qué los usuarios leerían "el aislamiento de compilación usará de forma predeterminada setuptools.build_meta " como implicando "que no podrás importar tu proyecto desde setup.py "? Los dos hechos me parecen ajenos ...

Personalmente, estoy de acuerdo con el enfoque actual de confiar en la existencia del archivo pyproject.toml. Los problemas, en mi opinión, provienen de personas que usan pyproject.toml para otras cosas además del empaque. Por lo tanto, la salida correcta es impulsar herramientas que no sean de empaquetado para ofrecer otra forma de configuración, de modo que las personas puedan elegir si usar pyproject.toml o no.

Pip en sí no (no debería, en mi opinión) considera si setup.py tiene razón al asumir que el directorio del proyecto está en sys.path, por lo que soy algo reacio a cambiar pip simplemente porque setuptools quiere empujar un diferente por defecto cuando se usa el backend.

Es cierto que pip supone que invocar los ganchos setuptools.build_meta es y debería ser perfectamente equivalente a llamar a setup.py . Ya hemos visto casos en los que no lo es, y creo que aún debe establecerse si ( setuptools ) queremos que el contrato de setuptools.build_meta sea ​​"esto es equivalente a llamar a python setup.py "o si en cambio queremos que sea" esta es una versión más cerrada y aislada de invocar setup.py directamente ".

Por supuesto, setuptools podría decir "ese no es el contrato de la función, así que no lo vamos a arreglar" y pip podría decir, "nuestra decisión fue que el valor predeterminado es PEP 517" y Ambos podemos decir que el error está en el otro proyecto, pero probablemente sea una buena idea coordinarlo.

Para decirlo de otra manera, incluso si pip advirtiera como sugieres, ¿por qué los usuarios leerían "el aislamiento de compilación usará por defecto setuptools.build_meta" como implicando "no podrás importar tu proyecto desde setup.py"? Los dos hechos me parecen ajenos ...

Pueden estar relacionados o no, pero también puede haber otros cambios en la semántica. El objetivo de una advertencia como esa es decir: "Por favor, sea explícito sobre cómo desea que suceda esta compilación, porque pronto lo incluiremos en algo que podría romper su compilación". Los proyectos pueden agregar el backend de compilación a su pyproject.toml anticipación y solucionar proactivamente cualquier rotura que pueda ocurrir.

También podríamos crear un backend PEP 517 "ficticio" en setuptools como setuptools.build_meta_legacy que solo chdir s en el directorio raíz e invoca setuptools.build_meta , de esa manera las personas pueden optar por el comportamiento anterior solo si lo necesitan antes de que comience a romperse.

Personalmente, estoy de acuerdo con el enfoque actual de confiar en la existencia del archivo pyproject.toml. Los problemas, en mi opinión, provienen de personas que usan pyproject.toml para otras cosas además del empaque.

Creo que necesitamos separar PEP 517 y PEP 518. PEP 518 enumera explícitamente cuáles son los "valores predeterminados" para el PEP, mientras que PEP 517 no especifica nada sobre cuál es el backend predeterminado.

Recuerdo que no me sentí terriblemente reacio a todo "la existencia de pyproject.toml te permite construir aislamiento", pero al verlo en la práctica, tampoco me gusta la idea de que especificar las dependencias de mi compilación aislada también optaría yo en setuptools.build_meta .

Tal vez la solución sea dividir la diferencia y tener el backend predeterminado en un setuptools.build_meta_legacy (que intenta mantener la semántica de setup.py ). De esa manera, al menos tendremos una forma de saber si un usuario tomó una decisión afirmativa para usar la nueva semántica o si simplemente no pensó en ello.

Un build_meta_legacy con un mensaje de advertencia me parece una solución razonable. Es probable que sea mejor hacer que la advertencia sea muy prominente (por ejemplo, durante la instalación y alentar a los usuarios a que presenten esto como un error al encargado de mantenimiento), con instrucciones claras sobre cómo se debe realizar la migración.

También debo señalar que la intención de pip (ese es el pip "corporativo" ;-) - lo que quiero decir es que los desarrolladores de pip discutieron esto un poco y llegaron a un consenso general de que sonaba como una idea razonable, pero aún no es un plan firme y depende de que alguien escriba realmente el código para que suceda) es que cambiamos relativamente rápido para pasar todos los proyectos a través de PEP 517 y descartar nuestra ruta de código heredado a través de setup.py completo. Hacer el backend de setuptools solo en pip 21.0 (para usar la versión sugerida desde arriba) elimina eso al menos 2 años adicionales.

mientras que PEP 517 no especifica nada sobre cuál es el backend predeterminado

Cierto. Pero en algún momento, pip se reducirá el apoyo caso especial de setuptools. Después de todo, ese es el objetivo (para nosotros, al menos) de PEP 517, desacoplar el frontend del backend y poner todos los backends en pie de igualdad. Entonces, cada vez que hacemos eso, tenemos que cometer un error si no hay backend o elegir un valor predeterminado (y optaremos por configurar herramientas de configuración por defecto, por razones heredadas). El debate aquí es cuándo hacemos eso, no si.

Actualmente, Pip tiene 2 rutas de código para instalaciones: la ruta PEP 517 y la ruta heredada setup.py . Esa es una fuente de problemas de mantenimiento y posibles errores. Optamos por hacer que PEP 517 sea el predeterminado si pyproject.toml estaba presente para garantizar el uso de la ruta PEP 517 (es poco probable que los proyectos se apresuren a agregar build-backend = setuptools.buid_meta , por lo que sin el comportamiento actual, las probabilidades son que las pruebas del código PEP 517 de pip y del backend de setuptools permanecerían cerca de cero durante un período prolongado). Hay una opción de exclusión en forma de --no-use-pep517 precisamente para atender los casos (supuestos raros) en los que el backend de setuptools no era adecuado.

No creo que nadie haya anticipado que setuptools querría tener diferencias semánticas entre setup.py y el backend, por lo que la posibilidad de que --no-use-pep517 sea ​​necesario para solucionar las diferencias semánticas con tanta frecuencia que debería ser el defecto ni siquiera se consideró.

También podríamos crear un backend PEP 517 "ficticio" en herramientas de configuración como setuptools.build_meta_legacy que simplemente ingresa en el directorio raíz e invoca setuptools.build_meta, de esa manera las personas pueden optar por el comportamiento anterior solo si lo necesitan antes de que comience a fallar. .

Esa puede ser una solución razonable. Pero tendría que estar al menos parcialmente documentado; como mínimo, pip documentaría que este era el valor predeterminado que asumiríamos. Si setuptools eligió dejar el backend sin documentar, es su elección, supongo.

No estoy seguro de la utilidad de cualquier discusión teórica adicional. Ciertamente, no creo que tenga nada más que añadir. Sugeriría que si alguien quiere llevar esto adelante, la mejor manera sería crear un RP cambiando el predeterminado, y la discusión sobre si queremos aceptarlo puede avanzar allí.

Para los mantenedores de paquetes que buscan resolver este problema para sus usuarios: publiqué una corrección que implementa la corrección sys.path .

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

Con suerte, esto puede funcionar como un recurso provisional para que podamos reflexionar sobre cómo se debe avanzar sin apresurarnos a encontrar una solución, o ralentizar innecesariamente la adopción de pip 19.0 (que contiene muchas más ventajas que solo PEP 517).

He publicado una corrección que implementa la corrección sys.path.

¡Eso es genial! Independientemente de la solución definitiva, este es un buen ejemplo de la flexibilidad del sistema de gancho PEP 517 :-)

Lo arreglé rebajando mi versión de pip por debajo de 19.x, luego intenté instalarlo y lo logré

Hay un tercer caso de uso: ¿qué pasa con los paquetes que proporcionan su propio backend de compilación? Por ejemplo: setuptools en sí solo enumera wheel como requisito de compilación:

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

Por supuesto, esto fallará si el código de pip para manejar PEP 517 no agrega el directorio fuente a sys.path .

Desde PEP 517:

Al importar la ruta del módulo, no buscamos en el directorio que contiene el árbol de fuentes, a menos que esté en sys.path de todos modos (por ejemplo, porque está especificado en PYTHONPATH). Aunque Python agrega automáticamente el directorio de trabajo a sys.path en algunas situaciones, el código para resolver el backend no debería verse afectado por esto.

Eso claramente (para mí) dice que los proyectos no deberían esperar poder ver su propio directorio de proyectos al resolver build-backend , por lo que setuptools debe agregarse a requires IMO. Y sí, entiendo que hacerlo es circular. Pero los backends de construcción que se construyen a sí mismos son por naturaleza bastante circulares de todos modos; ciertamente no son el caso normal.

Esa misma sección también me parece que confirma que las herramientas de compilación no deberían esperar que el directorio del proyecto esté en el sys.path del entorno de compilación.

¿Cómo funcionaría eso con --no-binary :all: ?

@pfmoore Una variante de la situación es que un paquete proporciona un sistema de construcción personalizado. El sistema de compilación no está instalado (y no forma parte de bdist), pero se suministra con sdist, tal vez para personalizar algún proceso de compilación. ¿Es este un caso de uso válido o el encargado de mantenimiento debe publicar el sistema de compilación personalizado como un paquete 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"]

¿Quizás una solución sería agregar una nueva configuración opcional, para indicar dónde encontrar módulos durante la compilación?

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

La configuración predeterminada es [] (lista vacía), lo que significa que no se agregan rutas (es decir, lo mismo que el comportamiento actual), pero los proyectos pueden agregar rutas para encontrar el sistema de compilación localmente.

Si build-system se omite por completo, la sección predeterminada es:

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

pip puede mostrar un mensaje de advertencia / información para decirle al usuario que migre (con un enlace a una página de documentación, probablemente).

Un beneficio adicional de esta solución es que todo se puede hacer en pip (el módulo pep517 vendido, en realidad). No es necesario cambiar nada en las herramientas de configuración o en los proyectos rotos existentes.

Una variante de la situación es que un paquete proporciona un sistema de construcción personalizado.

Sinceramente, no lo sé. No es una situación en la que haya pensado en mí. No sé si los autores del PEP lo consideraron; no recuerdo ninguna discusión sobre el tema cuando se estaba desarrollando el PEP.

En realidad, habiendo verificado, PEP 517 dice explícitamente (en la sección sobre build-backend ) "Al importar la ruta del módulo, no buscamos en el directorio que contiene el árbol de fuentes, a menos que esté en sys.path de todos modos "lo que implica para mí que se desaconseja explícitamente tener backends en el árbol. Si alguien podría solucionar esto con un código suficientemente tortuoso, no estoy seguro (pero sospecho que no).

El caso de uso esperado cuando desarrollamos PEP 517 fue que los backends se enviarían como ruedas en PyPI (o un índice personalizado) que se descargarían e instalarían en el entorno de compilación. La forma en que se construyeron los backends estaba explícitamente fuera del alcance; mi presunción personal era que no usarían los mecanismos PEP 517, sino que usarían un comando de nivel inferior ( setup.py bdist_wheel o flit build , por ejemplo ). El uso recursivo de un backend PEP 517 para construirse a sí mismo parecía un paso demasiado lejos en la complejidad. Se consideró como parte de la implementación de PEP 518 en pip (existe un potencial exploit fork bomb si un backend se envía como sdist y se usa a sí mismo para construirse a sí mismo, que tuvimos que prevenir antes de que pudiéramos incluso admitir backends no distribuidos como ruedas ) pero solo en el contexto de descargar el backend de PyPI.

tl; Dr; Todo lo que puedo ofrecer es mi recuerdo de las discusiones en ese momento; es mejor que busque en los archivos los antecedentes reales.

No sé si los autores del PEP lo consideraron; no recuerdo ninguna discusión sobre el tema cuando se estaba desarrollando el PEP.

Acabo de empezar a buscar en los archivos y parece que esta cuestión se debatió en detalle hacia el final del proceso (o al menos hasta bien entrado). No sé qué sitio web es mejor para ver los archivos, pero aquí hay un punto en el que la discusión comienza a hablar de esta pregunta nuevamente (28 de julio de 2017):
https://mail.python.org/pipermail/distutils-sig/2017-July/031109.html
https://www.mail-archive.com/[email protected]/msg26624.html

Por ejemplo, este correo electrónico en particular termina con:

Dada la cantidad de problemas que ya estamos teniendo con PEP 517, podría tener más sentido que PEP 517 simplemente ordene que el directorio no esté en sys.path, y haga un pequeño seguimiento de PEP solo para python-path.

Te haré saber si me encuentro con el veredicto final, pero animo a otros a leer por sí mismos.

¡Agradable! Gracias por encontrar eso :-)

Así que hojeé un montón de correos electrónicos, y creo que al menos puedes pasar al 29 de agosto, donde Nick parece estar sugiriendo que hay consenso sobre dejar el directorio de origen _out_ of sys.path:
https://mail.python.org/pipermail/distutils-sig/2017-August/031413.html
(Una a una, la gente se fue convenciendo de los argumentos de Nathaniel).

Sin embargo, en este mismo correo electrónico vinculado anteriormente, Nick dice lo siguiente :)

1. Si omitirlo es realmente un problema, es probable que lo averigüemos pronto como parte de la implementación de un backend setup.py

Aquí hay un párrafo más completo del correo electrónico:

Así que creo que podemos considerar que este se resolvió a favor de "Los frontends deben asegurarse de que el directorio actual NO esté en sys.path antes de importar el backend designado", ya que comenzar allí significará que maximizamos nuestras posibilidades de aprender algo nuevo como parte del Lanzamiento de la API aceptada provisionalmente.

Todavía no sé si hay correos electrónicos posteriores que alteren este resumen, pero no hay muchos correos electrónicos posteriores sobre el tema.

Gracias por rastrear los archivos por nosotros @cjerdonek. Declarando mi comprensión actual del problema:

1. Una gran cantidad de archivos setup.py del mundo real suponen actualmente que el directorio actual está en sys.path cuando se ejecutan, lo que crea extraños problemas de arranque cuando los proyectos se tratan a sí mismos como una dependencia en el tiempo de instalación
2. PEP 517 dice explícitamente que los extremos delanteros de construcción no deben implícitamente añadir el directorio actual a sys.path (que no dice nada acerca de backends)
3. pip 19.0 considera que pyproject.toml sin una sección build-system es equivalente a una sección build-system que especifica el backend setuptools
4. el backend setuptools PEP 517 tampoco agrega actualmente el directorio actual a sys.path (ya que alejarse del punto 1 anterior se considera un objetivo futuro deseable)
5. Hay dos soluciones provisionales disponibles para proyectos existentes, mientras que se mejoran los comportamientos predeterminados: fijar pip a menos de 19.0 y establecer explícitamente la opción --no-use-pep517 . Sin embargo, las personas solo las descubren después de descubrir por primera vez que actualizar pip rompe sus compilaciones.

Desde una perspectiva funcional, creo que el cambio clave que queremos introducir es que en el caso " pyproject.toml sin una sección build-system ", el directorio que contiene setup.py debería terminar en sys.path nuevo. Hay dos formas principales de manejar eso:

1. Obtén pip para hacerlo. Esto tiene el desafortunado efecto secundario de hacer que el comportamiento del front-end sea dependiente y, por lo tanto, posiblemente vea que los proyectos existentes no se instalan a menos que todos los frontends implementen la misma solución alternativa.
2. Obtenga el backend setuptools PEP 517 para hacerlo, inspeccionando pyproject.toml para una sección build-system e inyectando el directorio setup.py en sys.path si faltan la entrada de la sección y la ruta. Aún se necesita un nuevo pip en esa situación, ya que tiene que especificar una versión mínima de setuptools que maneje correctamente el caso "no build-system section".

En aras de que las cosas funcionen para los usuarios finales lo más rápido posible, sin pintarnos en ningún rincón de diseño desafortunado, en realidad propondría una resolución de 3 pasos:

1. Realice una nueva versión pip (19.0.1?) Ahora que agregue la entrada adicional sys.path para el caso "no build-system entrada". En este punto, el problema de compatibilidad debería desaparecer en gran medida para los usuarios finales.
2. Realice una nueva versión setuptools que maneje la adición de sys.path si la interfaz aún no lo ha hecho.
3. En una versión posterior de pip , cambie el caso "no build-system entrada" para eliminar la carcasa especial y, en su lugar, establezca una versión mínima más estricta para setuptools .

Esta propuesta se basa en el hecho de que creo que el backend setuptools PEP 517 es el lugar "correcto" para manejar los problemas de compatibilidad con versiones anteriores de setup.py , pero también creo que modificar pip directamente es probable que sea un cambio mucho más simple a corto plazo, y es un cambio que contendrá el problema mientras se trabaja en la solución más preferible desde el punto de vista arquitectónico.

He creado el backend build_meta_legacy en pypa / setuptools # 1652. Realmente preferiría que pip cambiara a usar setuptools.build_meta_legacy como el backend predeterminado, pero creo que crear un backend de "shim heredado" integrado es lo más lejos que puedo en setuptools . No quiero quedarme atascado indefinidamente en el soporte completo de " python setup.py install emulación" en el backend principal setuptools PEP 517.

Estoy un poco confundido por qué setuptools no quiere emular la ejecución del script de forma nativa aquí TBH. Parece que está pidiendo que los usuarios finales se confundan cuando python setup.py bdist_wheel funciona correctamente, pero pip wheel no (suponiendo que hayan configurado el backend de compilación no heredado).

¿Cuál es la razón fundamental?

¿Cuál es la razón fundamental?

Mi plan a largo plazo es desaprobar toda invocación directa de setup.py a favor de la invocación indirecta por parte de las interfaces PEP 517 o algo equivalente (para otros comandos). Si nos estamos moviendo a un mundo de "todos los entornos aislados", no quiero verme obligado a mantener la semántica de las invocaciones de comando setuptools compatible con la invocación de python setup.py , por la misma razón PEP 517 dijo específicamente que las interfaces no deberían hacer esto: tiene el potencial de romper el aislamiento de la compilación y, en general, crear situaciones indeseables.

Creo que es bastante raro que esto sea necesario, excepto como parte de un anti-patrón. Cualquiera que lo necesite legítimamente puede manipular fácilmente sys.path en su script de configuración.

Solo como nota, no creo que PEP 517 haya tenido como objetivo de diseño que todo el acceso a las herramientas de construcción fuera posible a través de los ganchos. Por ejemplo, flit tiene su propio conjunto de comandos flit build , etc., y no tengo la intención de desaprobarlos. Por lo tanto, es posible que encuentre casos extremos en los que la intención detrás de PEP 517 fuera que se necesitaran usar comandos específicos de la herramienta. Un ejemplo obvio es la construcción del backend en sí (como mencioné anteriormente), pero existen otros casos (no estandarizados actualmente, aunque los PEP futuros pueden agregar ganchos), como instalaciones editables y compilaciones in situ (reutilización de artefactos de compilaciones anteriores).

Conseguir el acuerdo de que todas las herramientas podrían admitir "build sdist" y "build wheel" fue lo suficientemente difícil como para no anticipar que la ampliación de la lista de operaciones estándar ocurrirá pronto.

Solo como nota, no creo que PEP 517 haya tenido como objetivo de diseño que todo el acceso a las herramientas de construcción fuera posible a través de los ganchos.

Esto no es lo que sugerí y es una digresión. Mi punto era que los problemas que hicieron necesaria la PEP 518 también existen de manera más general para todos los setup.py comandos, y esos son mejor resueltos por el desplazamiento de personas fuera de la invocación de setup.py en absoluto. No se necesita ningún estándar para hacer esto de la misma manera flit no necesita un PEP para agregar subcomandos.

Ah, vale. Perdón por el malentendido.

La transición propuesta por @ncoghlan me parece buena. Si nadie tiene problemas con eso, sigamos adelante.

¡Gracias por desenterrar los archivos @cjerdonek!

Dado que ya existe un PR que corrige esto en las herramientas de configuración (a través de la introducción del backend heredado). ¿Hay alguna razón para no omitir el paso 1 de arriba? Estamos instalando herramientas de configuración en un entorno de compilación aislado, por lo que depender de una versión muy reciente no debería ser un problema.

¿Hay alguna razón para no omitir el paso 1 de arriba?

No Podemos aumentar directamente la versión mínima requerida actual.

Mi plan de transición se basa en la suposición de que la gente necesitará más tiempo para resolver el mecanismo de transición de larga duración en el lado setuptools , mientras que el backend de transición dedicado de @pganssle parece prometedor en ese frente, estoy No estoy seguro de que tenga sentido dejar el statu quo mientras se revisa ese cambio.

Dicho esto, no estoy familiarizado con los detalles de cómo funciona la implementación de PEP 517 en pip , por lo que mi suposición de que solucionar el problema en la interfaz sería sencillo puede ser incorrecta.

Debido a que los backends se ejecutan en un subproceso (y de hecho, usando el proyecto vendido pep517 , que agrega un nivel adicional de indirección), no me resulta del todo obvio cómo estableceríamos sys.path para un gancho de backend. Como mínimo, necesitaríamos involucrar PYTHONPATH que significa preocuparse por los casos en los que el usuario ya tiene PYTHONPATH establecido y cómo lo usa el código de aislamiento.

Esencialmente, sospecho que establecer sys.path en pip es claramente no trivial. Es poco probable que tenga tiempo para analizar los detalles, y mucho menos escribir un parche (¡y asegurarme de que esté probado correctamente!).

Creo que conseguir un backend de setuptools fijo es la forma más rápida de avanzar.

Mi plan a largo plazo es descartar toda invocación directa de setup.py a favor de la invocación indirecta por parte de las interfaces PEP 517 o algo equivalente (para otros comandos).

@pganssle ouch. Los setup.py procedimentales deben morir. No debería existir por ningún motivo. Porque esta "flexibilidad" es una fuente inagotable de dolor y colapsos. Es imposible migrar setup.py y, por lo tanto, todos los problemas con el empaquetado de Python.

Reemplazaría setup.py con package.json y simplemente agregaría la sección de Python en lugar de otro formato de descripción de paquete.

Al menos entonces puedo usar especificadores de versión ==1.x .

@techtonik Por favor, vete. Sus contribuciones no constructivas no son bienvenidas en ningún proyecto en el que participe.

Trabajar en # 6210 me ha permitido responder mi propia pregunta de arriba sobre qué tan difícil será abordar esto en el nivel pip : el desafío es que la información sobre si el directorio de origen debe insertarse o no como sys.path[0] debe ser tunelizado desde el código que lee pyproject.toml hasta el llamador de gancho PEP 517, y luego desde allí al guión envoltorio en proceso real.

Esos son factibles sin cambios arquitectónicos importantes (un prefijo pip._implicit. en el nombre del backend de compilación para la primera parte, y una var PEP517_SYS_PATH_0 env para la última), pero significa modificar temporalmente la pep517 vendored setuptools esté lista.

Mi plan de transición se basa en la suposición de que la gente necesitará más tiempo para resolver el mecanismo de transición de larga duración en el lado de las herramientas de configuración, mientras que el backend de transición dedicado de @pganssle parece prometedor en ese frente, no estoy seguro de que tenga sentido para dejar el status quo en su lugar mientras se revisa ese cambio.

Sí, estoy de acuerdo con esto. Sugerí solo esto en una publicación de distutils, hay dos cosas que diría que son importantes:

1. Obtener una solución para los usuarios lo antes posible
2. Poner en marcha la transición correcta .

Personalmente, creo que lo correcto es eliminar la "existencia de pyproject.toml le permite participar en la lógica PEP 517" hasta que tengamos la lógica de transición en su lugar. Teniendo en cuenta que los cambios en setuptools tienen consecuencias para su API pública y en pip solo retrasaría lo que resultó ser un cambio incompatible con versiones anteriores, para mí tiene sentido haga la solución rápida en pip mientras revisamos el camino a seguir para setuptools .

Con ambos enfoques operativos en mi máquina local, probé tanto el # 6210 como el # 6212 contra el requisito problemático original PyInstaller==3.4 .

• # 6210 funcionó como se desea: https://github.com/pypa/pip/pull/6210#issuecomment -458144828
• # 6212 no se comporta como se esperaba: https://github.com/pypa/pip/pull/6212#issuecomment -458148519

No sé si la falla # 6212 es un problema de configuración de prueba, o si en realidad hay un problema adicional en la versión preliminar de las herramientas de configuración, solo sé que hay más trabajo de integración por hacer antes de que podamos confiar en esa solución. mientras que ahora confío en el # 6210, lo único malo es que es un truco de compatibilidad horrible que no queremos que pip tenga que llevar para siempre.

Parece que --no-cache es responsable del error assert en # 6212. Probar con --cache-dir lugar dio una prueba local exitosa: https://github.com/pypa/pip/pull/6212#issuecomment -458166386

(Voy a estar fuera de línea durante ~ 18 horas para dormir y trabajar, por lo que la gente debe sentirse libre de correr con el número 6210 o 6212 que tenga sentido mientras tanto)

Actualicé el título para reflejar mejor la situación. ¡Gracias @ncoghlan por las relaciones

Nota de moderación: también he ocultado los comentarios no productivos (y las respuestas a ellos) como "Fuera de tema", y lo haré para cualquier comentario futuro en ese sentido. Si alguien quiere tener una discusión sobre la moderación, presente un nuevo problema o envíeme un ping por correo electrónico; este hilo no es el lugar adecuado para plantear cualquier problema con la moderación que pueda tener.

También seguí adelante y fijé esto para evitar que las personas creen duplicados y para indicar claramente que sabemos sobre esto.

Incluso si hacemos la suscripción de pep517, este es un cambio de comportamiento que no se anunció y, por lo tanto, romperá las bibliotecas _aunque ya hayan optado por hacerlo_ (consulte PyInstaller , por ejemplo). En el caso de que una biblioteca declare una suscripción a las compilaciones pep517 _ e_ importe localmente cosas que espera encontrar en sys.path , pip no realiza ninguna suposición (porque la biblioteca es explícita) pero la biblioteca es todavía roto de repente.

En ese caso, realmente no veo una alternativa además de incluir cwd en las herramientas de configuración, porque esto está roto. A menos que la propuesta sea decirle a la gente que regrese y arregle las versiones que cortaron entre pep517 y pip 19, que, si algún usuario tiene esas versiones estrictamente fijadas, de repente puede dejar de ser instalable, realmente creo que deberíamos considerar el impacto de estas decisiones sobre la experiencia del usuario. Según esta discusión y las propuestas actuales, algunas de estas bibliotecas no se podrán instalar con nuevas versiones de pip + setuptools en el futuro utilizando los valores predeterminados a menos que las compilaciones pep517 estén explícitamente deshabilitadas.

Esto es bastante impactante si solo está tratando de instalar un paquete con las herramientas que le proporciona Python, pero en realidad no puede instalar las cosas de forma aleatoria. Digo esto para desviar la atención de los aspectos técnicos por un momento y sobre el impacto en el usuario final que puede frustrarse con las herramientas, el ecosistema, las bibliotecas o el lenguaje en sí, porque de repente (y sí, solo bajo circunstancias específicas), las cosas que podrían instalar bien ahora no se pueden instalar. Realmente creo que deberíamos cerrar esta brecha en cualquier solución que se implemente.

Actualmente usamos una pila de fallas para manejar instalaciones fallidas en pipenv y estoy agregando --no-use-pep517 cuando esté disponible para manejar fallas como resultado de estos cambios. No estoy seguro de que sea intuitivo para el usuario promedio, ya que probablemente ni siquiera esté claro de inmediato cuál es la causa del problema. Digo esto solo para señalar que tenemos una solución, pero se siente importante tratar de cerrar esta brecha para ayudar un poco a los usuarios en este caso.

(editar: también muchas gracias a pganssle, cjerdonek, pfmoore, pradyunsg, ncoghlan y a todos los demás que han dedicado mucho tiempo y esfuerzo a esto)

El caso de uso esperado cuando desarrollamos PEP 517 fue que los backends se enviarían como ruedas en PyPI (o un índice personalizado) que se descargarían e instalarían en el entorno de compilación. La forma en que se construyeron los backends estaba explícitamente fuera de alcance; mi presunción personal era que no usarían los mecanismos PEP 517, sino que usarían un comando de nivel inferior (setup.py bdist_wheel o flit build, por ejemplo). El uso recursivo de un backend PEP 517 para construirse a sí mismo parecía un paso demasiado lejos en la complejidad. Se consideró como parte de la implementación de PEP 518 en pip (existe un potencial exploit fork bomb si un backend se envía como sdist y se usa a sí mismo para construirse a sí mismo, que tuvimos que prevenir antes de que pudiéramos incluso admitir backends no distribuidos como ruedas ) pero solo en el contexto de descargar el backend de PyPI.

Solo para volver a esto: el nuevo setuptools.build_meta_legacy predeterminado resuelve el problema de usar PEP 517 para todo excepto los backends de PEP 517, que es un problema para setuptools sí. Si no resolvemos eso, entonces como @ benoit-pierre señala en pypa / setuptools # 1644, no será posible que la gente use pip install --no-binary :all: para ningún proyecto que dependa de setuptools (o presumiblemente cualquier proveedor de backend PEP 517).

¿Deberíamos discutir eso en este hilo o crear un nuevo hilo para discutirlo?

¿Deberíamos discutir eso en este hilo o crear un nuevo hilo para discutirlo?

Yo dividiría eso. Mi sensación inmediata es que el problema es que --no-binary :all: tiene consecuencias no deseadas significativas aquí (similar en la práctica al impacto de usar esa bandera en presencia de un proyecto que solo distribuye ruedas, no sdists) y me gustaría para evitar digresiones sobre (por ejemplo) la conveniencia de usar --no-binary :all: para distraer aún más de este hilo.

No creo que la fijación de la cuestión con --no-binary :all: construcción de backends de construcción es ni de lejos tan crítico como éste. Si un usuario ya está especificando --no-binary :all: , puede agregar --no-use-pep517 relativa facilidad.

Nuevo PR # 6229 que:

1. Implementa la solución provisional sugerida por @pganssle de hacer que una sección build-system en pyproject.toml el requisito inicial para optar automáticamente a PEP 517 (aplazando la opción "cualquier archivo pyproject.toml " en una versión posterior)
2. Agrega 3 casos de prueba dedicados que cubren la importación de un paquete adyacente desde setup.py

Voy a cerrar los otros 2 PR a favor de ese, ya que es la solución mínima que debería hacer que las cosas funcionen nuevamente para los usuarios finales, y no requiere ningún truco horrible como el # 6210 o una nueva versión de herramientas de configuración como el # 6212

Entonces, ¿dónde deja eso setuptools.build_meta_legacy ? ¿La propuesta ahora requiere que los proyectos que necesitan la funcionalidad "importar paquete adyacente" lo especifiquen explícitamente en pyproject.toml ? Si es así, sugiero encarecidamente que se debe documentar en algún lugar, junto con el hecho de que la importación de paquetes adyacentes sin esa especificación está en desuso y se eliminará en el pip 19.X (debemos acordar qué es X), no podemos hacer eso una desaprobación programática (no lo creo), pero esa es una razón más para documentarlo claramente, para que no seamos acusados ​​(nuevamente) de eliminar la funcionalidad sin previo aviso.

Editar: Pero por lo demás, gracias por las nuevas relaciones públicas y el resumen.

Edición 2: Veo que cerró la propuesta setuptools.build_meta_legacy . No estoy seguro de que me guste, ya que nos pierde la oportunidad de decir ahora cuál es nuestro plan a más largo plazo, extendiendo cualquier período de depreciación, como mencioné anteriormente ...

@pfmoore No, significa que volver al comportamiento deseado debería estar cubierto por un nuevo problema asociado con la eliminación de la solución alternativa # 6163 (probablemente actualizando a setuptools que proporciona setuptools.build_meta_legacy ).

Editar: por ahora acabo de reabrir # 6212, pero lo retitulé para dejar en claro que no creo que debamos esperar a que se resuelva toda la discusión de build_meta_legacy antes de corregir los comandos de instalación que actualmente fallan.

Mi propuesta fue en realidad que la suscripción para PEP 517 especifica build-system.build-backend no la existencia de build-system en absoluto, y que entre ahora y la versión 19.1, setuptools agregaría build_meta_legacy y pip lo usarían como el backend predeterminado.

Estoy de acuerdo en que en 19.1, probablemente si pip no puede encontrar setuptools.build_meta_legacy , debería volver a la ruta del código anterior. Eso nos dará cambios mínimos de ruptura al optar por el número máximo de personas.

Mi propuesta fue en realidad que la opción de inclusión de PEP 517 especifica build-system.build-backend

... que se puede manejar simplemente configurando use_pep517 = False en el caso de respaldo (en lugar de configurarlo en has_pyproject que es lo que hacemos ahora.

en 19.1, probablemente si pip no puede encontrar setuptools.build_meta_legacy, debería volver a la ruta del código anterior

No creo que valga la pena hacerlo. Especificaremos una versión de setuptools suficientemente reciente que estamos seguros de que obtendremos el backend heredado, y no hay necesidad de considerar la posibilidad de que setuptools elimine ese backend en una versión futura (o más bien, si lo hacen, simplemente culpelos por los problemas resultantes ;-))

Nota: el use_pep517 = False predeterminado

1. El caso " build-system.requires está configurado" tiene que usar aislamiento de compilación, para que pueda instalar las dependencias solicitadas sin afectar el entorno principal. La forma más fácil de hacerlo dada la estructura del código actual es establecer use_pep517 = True en este caso, así que hice eso y obtuve el caso de prueba nuevamente.
2. Una tabla [build-system] falta indica que pyproject.toml solo se está usando para almacenar configuraciones en la tabla [tools] , por lo que tiene que resultar en use_pep517 = False para ser una solución alternativa efectiva para el problema informado originalmente, por lo que marqué este caso de prueba como un error esperado.
3. Eso deja el caso "vacío [build-system] mesa", que creo que puede resolverse razonablemente en cualquier dirección. Sin embargo, como no creo que este caso en particular vaya a surgir muy a menudo en la práctica (¿por qué alguien se tomaría la molestia de agregar una tabla build-system sin configurar requires o build-backend ?), Elegí resolverlo de una manera que significara que el caso de prueba PEP 518 previamente definido pasó, en lugar de agregar un segundo marcador de falla esperada.

Para resolver 3 en la otra dirección, necesitaríamos cambiar la línea:

use_pep517 = build_system is not None

en lugar de ser:

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

De esa manera, solo un requisito no vacío optaría por el aislamiento de compilación PEP 517 (lo que también significaría agregar un cuarto caso de prueba, ya que los campos build-system.requires vacíos y no vacíos ahora se comportarían de manera diferente).

Perdón por la contribución no solicitada aquí, pero no puedo dejar de notar que todo esto se siente como una forma bastante elaborada de evitar tener el cwd en sys.path y, en última instancia, dejará cosas rotas que solían funcionar, lo que se siente bastante perturbador. desde una perspectiva de UX.

Esto afecta a un número considerable de usuarios y paquetes. Al menos algunos de ellos tienen una sección [build-system] definida y _también_ se basan en el comportamiento anterior y, por lo tanto, permanecerán rotos para cualquiera que tenga esas versiones ancladas.

@techalchemy Sí, la suposición original en pip era que setuptools.build_meta funcionaba de la misma manera desde una perspectiva sys.path que la invocación directa de setup.py , y esa suposición resultó incorrecto. Una vez que esté disponible una versión setuptools contenga el backend setuptools.build_meta_legacy definido en https://github.com/pypa/setuptools/pull/1652, se podrá completar # 6212, y ese sería el largo resolución de término. Sin embargo, no hay una ETA actual para dicha versión, por lo que debemos continuar explorando las resoluciones de pip -only para recuperar el directorio de origen en sys.path para paquetes que no son explícitamente nativos de PEP 517 ".

En # 6229 implementé la sugerencia de @pganssle de simplemente posponer la adopción de "PEP 517 por defecto", pero parece que eso causa más problemas de los que resuelve debido a otro cambio en pip 19: el procesamiento de build-system.requires ahora está vinculado al procesamiento de build-system.build-backend , por lo que --no-use-pep517 deshabilita PEP 518 (lo que causa fallas en el conjunto de pruebas y también puede causar fallas de instalación en el mundo real si la compilación las dependencias no están preinstaladas).

En # 6210, en lugar de eso, parcheo localmente pep517 para admitir la inyección de sys.path[0] en el subproceso, haciendo efectivamente lo mismo que se espera que haga setuptools.build_meta_legacy en un futuro setutpools lanzamiento. Esto parece comportarse de la manera que queremos - build-system.requires todavía se procesa, y el directorio de origen es sys.path[0] cuando se ejecuta setup.py . También es muy similar a lo que propuse en https://discuss.python.org/t/pep-517-backend-bootstrapping/789/29?u=ncoghlan y @takluyver ha redactado en https://github.com/ pypa / pep517 / pull / 42 / para manejar backends auto-bootstrapping de una manera que sea compatible con --no-binary :all:

Perdón por ser el RM AWOL. Pasaron cosas que no había anticipado.

Obviamente, prefiero la solución del lado de las herramientas de configuración para esto, pero el # 6210 también me parece bien, como una solución a corto plazo.

Estoy de acuerdo con @techalchemy y @pradyunsg ; creo que la solución del lado de las herramientas de configuración es el enfoque correcto aquí. Si bien aprecio el trabajo para tratar de encontrar una solución rápida dentro de pip, ¿no sería mejor gastar ese tiempo en acelerar una nueva versión de setuptools con _build_meta_legacy ? No he estado observando lo que está sucediendo en las herramientas de configuración, por lo que no tengo claro por qué hay un problema con la publicación de una solución rápida en las herramientas de configuración (los ciclos de lanzamiento de las herramientas de configuración son mucho más rápidos que los de pip).

Estoy de acuerdo con una solución de pip a corto plazo, pero me gustaría aclarar cuándo podemos esperar una solución de herramientas de configuración.

¡Hola a todos!

Tengo el mismo 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'**

¿Alguien sabe si el problema está resuelto? ¿O cómo solucionarlo temporalmente?

¡Gracias a todos!

@ jce94 , usa pip <19 por ahora.

@altendky gracias por la info!

No pude resolver este problema con las soluciones alternativas sugeridas mientras trabajaba con pipenv . Congelar pip a 18.1 en Pipfile parece no tener ningún efecto ya que pipenv sigue forzando la última versión de pip. Puedo configurar manualmente pip en 18.1, pero cuando vuelva a crear el entorno virtual pipenv, Pipenv se actualizaría al último pip sin importar qué ... ¿Alguna recomendación para que se mantenga?

@altendky Lamentablemente, usar una versión predefinida de pip no es posible en ese momento para los usuarios de pipenv (y también creo que para la poesía ). Ambos usan las últimas versiones. Supongo que, por ahora, mucha gente tiene tuberías rotas.

Lo que es aún más extraño, no está sucediendo de manera constante. He vuelto a ejecutar un trabajo de Appveyor, el primero pasó, el segundo falló, aunque son estrictamente idénticos

En caso de que alguien se esté preguntando acerca de la línea de tiempo, espero que podamos tener una solución lista para el final de esta semana o principios de la próxima semana y hacer una versión posterior de corrección de errores de pip poco después.

La nueva versión de setuptools, versión 40.8.0 ahora está disponible con el backend build_meta:__legacy__ .

¡Gracias! ¿Y es esto algo que deberíamos apuntar a PyInstaller para usar? Ellos eran
bastante descontento con los cambios ... Cualquier documentación o PEP que pueda presentar
con ellos para apoyar los cambios?

El martes 5 de febrero de 2019 a las 10:24 Paul Ganssle < [email protected] escribió:

La nueva versión de setuptools, la versión 40.8.0 ya está disponible con la
build_meta: __ legacy__ backend.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/pypa/pip/issues/6163#issuecomment-460747909 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ADtXZjnOfu56IYR6VEKK4yowMg3XdcFEks5vKcxBgaJpZM4aNvmP
.

@AlmogCohen No, esto no es algo que deba usar directamente, es solo para que lo usen los front- pip comience a usar build_meta:__legacy__ como su backend predeterminado. Esto no es procesable desde la perspectiva del usuario final.

¿Alguna ETA en la nueva versión que integrará la solución?

En unas pocas horas. :)

Vea el problema fijado.

pip 19.0.2 ha sido lanzado con una solución para esto.

No puedo instalar pyinstaller con la última versión de pip, incluso cuando 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 hilo se ha bloqueado automáticamente ya que no ha habido ninguna actividad reciente después de que se cerró. Abra un nuevo problema para errores relacionados.