<p>pip 19.0 не может установить пакеты, которые импортируют подлежащий установке пакет из CWD</p>

Это похоже на проблему с тем, как pyinstaller импортирует себя для установки.

Было бы неплохо сообщить о проблеме ребятам из PyInstaller.

В настоящее время мы используем 18.1, и обновление до 19.0 также вызывает у нас эту проблему. В репозитории PyInstaller есть связанная проблема, потому что pip '' не находится в sys.path.

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

Я думаю, что это довольно распространенный рабочий процесс. Вы помещаете __version__ = "1.2.3" в foo/__init__.py а затем делаете import foo в setup.py чтобы вам не приходилось указывать версию в двух местах. И любой пользователь библиотеки может проверить версию в соответствии с PEP 396 .

# foo/__init__.py
__version__ = "1.2.3"

# setup.py
from setuptools import setup

import foo

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

Кроме того, это происходит только в том случае, если у вас есть файл pyproject.toml (и setup.py ). Удалите его, и установка работает нормально. Так что, похоже, здесь есть некоторые различия в поведении. Может быть, традиционный способ изменяет sys.path / PYTHONPATH ?

Ах, я думаю, что понимаю, что происходит. Поскольку, используя файл pyproject.toml , вы в основном говорите pip, что хотите использовать PEP 517/518.

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

Вышеупомянутое говорит pip, что ему нужны setuptools и wheel для сборки PyInstaller. Но в случае с PyInstaller это также есть в его setup.py :

# setup.py
from PyInstaller import __version__

С точки зрения PEP 517, помимо setuptools и wheel , это означает, что он сам должен построить. Что, конечно, немного странно.

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

Как упоминал @cjerdonek в https://github.com/pypa/pip/issues/6175#issuecomment -456769285, может ли кто-нибудь проверить, исправляет ли --no-use-pep517 это для них?

Я подозреваю, что причина этой проблемы в том, что изоляция сборки или код PEP 517 не гарантирует, что корень каталога пакета находится в sys.path, потому что у pandas есть versioneer.py, сидящий рядом с setup.py. Я вспоминаю, как это всплывало в какой-то момент, но я не припоминаю, что это была за дискуссия. Это может рассматриваться как проблема с бэкэндом сборки setuptools вместо pip, или это может быть ошибка механизма изоляции pip.

[...] может кто-нибудь проверить, исправляет ли --no-use-pep517 это для них?

PyInstaller отлично устанавливается с --no-use-pep517 .

Хорошо, тогда это определенно проблема с новым кодом PEP 517, и я почти уверен, что проблема просто в том, что каталог, содержащий корень проекта, не был добавлен в sys.path . Может быть, @pfmoore лучше

Если это поможет другой пример этого (через apache-airflow is pip install pendulum==1.4.4 не работает, но pip install --no-use-pep517 pendulum==1.4.4 работает.

Полученная нами трассировка стека аналогична:

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'

Также установка следующего также не работает с pip v 19.0, но будет при использовании --no-use-pep5517:
pendulum == 1.5.0 (AttributeError: модуль enum не имеет атрибута IntFlag)
pendulum == 1.5.1 (AttributeError: модуль enum не имеет атрибута IntFlag)
маятник == 2.0.0 (AttributeError: модуль enum не имеет атрибута IntFlag)
pendulum == 2.0.1 (AttributeError: модуль enum не имеет атрибута IntFlag)
pendulum == 2.0.2 (AttributeError: модуль enum не имеет атрибута IntFlag)

В то время как 2.0.3 и 2.0.4 устанавливаются нормально.

cartopy (по крайней мере, их последний выпуск) также не устанавливается с 19.0, не удается импортировать его versioneer.py, который находится рядом с setup.py

Это также проблема с некоторыми проектами, над которыми я работаю. Мы используем pyproject.toml для определения наших параметров python black и делаем аналогичный from project.version import __version__ в нашем setup.py.

По крайней мере, мне кажется, что достаточно было бы определить отсутствие изоляции проекта в pyproject.toml. Мне кажется неразумным заставлять любого, кто хочет установить проект, использовать --no-buid-isolation или --no-use-pep517

Похоже, что сбой произошел в get_requires_for_build_wheel , и бэкэнд setuptools запускает setup.py чтобы выполнить своего рода самоанализ для определения требований сборки (конкретный код здесь ). Мне этот код кажется странным, и я не понимаю, зачем он нужен. Я изначально полагаю, что это ошибка в бэкэнде setuptools, которую они должны исправить.

PEP 517 не утверждает, что внешние интерфейсы должны запускать хуки в среде, которая добавляет каталог сборки в sys.path , и есть потенциальная проблема, что если мы это сделаем, это может нарушить изоляцию (если каталог сборки содержит копию некоторый обязательный, но не указанный пакет, например). Поэтому я бы предпочел не добавлять каталог сборки в sys.path . Но это может быть целесообразно, если это предлагает быстрое решение этой регрессии. Однако я не думаю, что проекты должны полагаться на это.

Резюме:

1. Об этом следует сообщить в setuptools для рассмотрения в качестве внутренней проблемы. Я бы подумал о том, чтобы исправить это в бэкэнде setuptools (возможно, просто добавив каталог сборки в sys.path ) как идеальное решение.
2. Если setuptools этого не делает, pip может добавить каталог сборки в sys.path , но я не думаю, что PEP 517 рассматривает это как ответственность внешнего интерфейса ..
3. Требование, чтобы каталог сборки был видимым для хуков на sys.path , потребует как минимум разъяснения PEP.

Я не думаю, что этот сценарий рассматривался при разработке PEP 517. Может быть, потому что он специфичен для setuptools (или, скорее, специфичен для бэкэндов, которые запускают произвольный код Python как часть сборки).

Я думаю, что люди довольно часто импортируют что-то из текущего каталога в setup.py и обычно обрабатывают вещи так, как если бы setup.py находится в $PWD .

Я думаю, что разумно возложить эту ответственность на setuptools , поскольку это, вероятно, единственный проект, которому это действительно нужно.

Да, подумав об этом еще раз, я уверен, что это ответственность за бэкэнд setuptools. До PEP 517 pip запускал setup.py как сценарий, поэтому стандартные правила Python помещают каталог сценария в sys.path . В рамках PEP 517 вызов setup.py заменяется вызовами внутренних обработчиков, поэтому эти хуки должны сохранять семантику. Поскольку setuptools запускает setup.py в процессе из хуков, он должен сам управлять sys.path . Надеюсь, для них это не проблема. @jeanlaroche (или кто-то другой,

[...] может кто-нибудь проверить, исправляет ли --no-use-pep517 это для них?

Я могу подтвердить, что --no-use-pep517 позволяет pip install pandas добиться успеха.

Я также могу подтвердить, что использование --no-use-pep517 работает для всех моих неработающих пакетов

успех и для меня

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

Я не думаю, что это ошибка в pip / setuptools, из того, что я читал в разделе «Среда сборки» PEP 517, кажется, что ничего о среде не следует предполагать, за исключением того, что зависимости, объявленные в pyproject.toml , доступны.

Также не является ли импорт устанавливаемого пакета из setup.py плохой практикой? Есть гораздо лучшие способы хранения версии пакета в одном месте, например, как описано в этом руководстве по упаковке от PyPA.

В обсуждении в pypa / setuptools # 1642 я и перестать полагаться на тот факт, что . находится в sys.path когда вы выполняете python, и начните продвигать людей к более явной семантике.

Основная проблема здесь в том, что простое присутствие pyproject.toml заставляет людей выбирать как PEP 518, так и PEP 517, поэтому, даже если вы не указали серверную часть сборки, вы внезапно получаете новую семантику.

Является ли это решение по части pip необратимым на данный момент? Может быть, у нас может быть наличие pyproject.toml вы могли подключиться к PEP 518, но PEP 517 не запускается, если вы действительно не укажете серверную часть сборки?

Честно говоря, ситуация сложная, но я думаю, что pip легче предупредить об этом, чем setuptools . Если мы сейчас включим PEP 517 и скажем, что наличие pyproject.toml начнет запускать PEP 517 после 20.0 или 21.0, мы можем создать руководство по миграции и начать выдавать предупреждения в pip для этого - " build-backend отсутствует в pyproject.toml , имейте в виду, что после версии 21.0 изоляция сборки по умолчанию будет использовать setuptools.build_meta , см. руководство по миграции на ..."

Также не является ли импорт устанавливаемого пакета из setup.py плохой практикой? Есть гораздо лучшие способы хранения версии пакета в одном месте, например, как описано в этом руководстве по упаковке от PyPA.

Честно говоря, это руководство определяет импорт устанавливаемого пакета из setup.py как стратегию 6, так что это определенно довольно распространено. На этом этапе, если мы отходим от такой стратегии, эту страницу следует обновить, чтобы она больше не включалась.

Решение инициировать PEP 517 при наличии pyproject.toml было осознанным выбором (обсуждение, вероятно, касалось проблемы реализации PEP 517 или PR, но у меня сейчас нет времени, чтобы найти его). Очевидно, что это можно изменить в свете того, что мы здесь видим, но мы не должны этого делать без должного рассмотрения причин, по которым мы приняли это решение.

Сам Pip не (не должен, IMO) принимать во внимание, правильно ли setup.py предполагать, что каталог проекта находится на sys.path , поэтому я несколько не хочу просто менять pip потому что setuptools хочет установить другое значение по умолчанию при использовании серверной части. Хотя я согласен с тем, что импорт проекта, создаваемого в setup.py имеет ряд трудностей, это не похоже на то, что до сих пор вызывало предупреждения, поэтому я предположил, что бэкэнд должен поддерживать эту семантику. Другими словами, даже если pip действительно предупредил, как вы предлагаете, почему пользователи читают "изоляция сборки по умолчанию будет использовать setuptools.build_meta " как подразумевающую "вы не сможете импортировать свой проект из setup.py "? Мне кажется, что эти два факта не имеют отношения к делу ...

Лично я согласен с нынешним подходом, основанным на существовании файла pyproject.toml. Проблемы IMO возникают из-за людей, использующих pyproject.toml для других вещей, кроме упаковки. Таким образом, правильный выход - продвигать инструменты без упаковки, чтобы предложить другой способ настройки, чтобы люди могли выбирать, использовать pyproject.toml или нет.

Сам Pip не (не должен, ИМО) смотреть на то, правильно ли setup.py предполагать, что каталог проекта находится на sys.path, поэтому я несколько не хочу менять pip просто потому, что setuptools хочет нажать другое значение по умолчанию при использовании серверной части.

Верно, просто pip делает предположение, что вызов setuptools.build_meta hooks является и должен быть полностью эквивалентен вызову setup.py . Мы уже видели случаи, когда это не так, и я думаю, что еще предстоит установить, хотим ли мы ( setuptools ), чтобы контракт setuptools.build_meta был "это эквивалентно вызову python setup.py "или, если мы хотим, чтобы это было" это более закрытая и изолированная версия прямого вызова setup.py ".

Конечно, setuptools может сказать «это не контракт функции, поэтому мы не собираемся его исправлять», а pip мог бы сказать: «мы решили, что по умолчанию используется PEP 517» и мы оба можем сказать, что ошибка находится в другом проекте, но, вероятно, это хорошая идея для координации.

Другими словами, даже если pip предупреждал, как вы предлагаете, почему пользователи читают «изоляция сборки по умолчанию будет использовать setuptools.build_meta» как подразумевающую «вы не сможете импортировать свой проект из setup.py»? Мне кажется, что эти два факта не имеют отношения к делу ...

Они могут быть связаны, а могут и не быть связаны, но могут быть и другие изменения в семантике. Смысл подобного предупреждения состоит в том, чтобы сказать: «Пожалуйста, четко укажите, как вы хотите, чтобы эта сборка происходила, потому что скоро мы собираемся включить вас в то, что может нарушить вашу сборку». Проекты могут заранее добавить серверную часть сборки в свои pyproject.toml заранее исправить любые поломки, которые могут произойти.

Мы также могли бы создать «фиктивный» бэкэнд PEP 517 в setuptools например setuptools.build_meta_legacy который просто chdir s в корневой каталог и таким образом будет вызывать setuptools.build_meta люди могут выбрать старое поведение, только если оно им нужно, прежде чем оно начнет ломаться.

Лично я согласен с нынешним подходом, основанным на существовании файла pyproject.toml. Проблемы IMO возникают из-за людей, использующих pyproject.toml для других вещей, кроме упаковки.

Я думаю, что нам нужно разделить PEP 517 и PEP 518. PEP 518 явно перечисляет «значения по умолчанию» для PEP, тогда как PEP 517 ничего не указывает о том, что такое бэкэнд по умолчанию.

Я помню, что не испытывал ужасного отвращения ко всему, что «существование pyproject.toml вам создать изоляцию», но, видя это на практике, мне также не нравится идея, что указание зависимостей моей изолированной сборки также будет меня в setuptools.build_meta .

Возможно, решение состоит в том, чтобы разделить разницу и установить бэкэнд по умолчанию на недокументированный setuptools.build_meta_legacy (который пытается сохранить семантику setup.py ). Таким образом, мы, по крайней мере, сможем определить, сделал ли пользователь утвердительный выбор использовать новую семантику или просто не подумал об этом.

build_meta_legacy с предупреждением звучит для меня как разумное решение. Вероятно, лучше сделать предупреждение очень заметным (например, во время установки и побудить пользователей сообщить об этом сопровождающему как об ошибке) с четкими инструкциями по выполнению миграции.

Я также должен отметить намерение pip (это «корпоративный» pip ;-) - я имею в виду, что разработчики pip немного обсудили это и пришли к общему мнению, что это звучит как разумная идея, но это еще не твердый план и это зависит от того, что кто-то действительно напишет код, чтобы это произошло) заключается в том, что мы относительно быстро переключаемся на передачу всех проектов через PEP 517 и полностью отбрасываем наш устаревший кодовый путь через setup.py . Создание бэкэнда setuptools только в pip 21.0 (для использования предложенного выше выпуска) отодвигает это как минимум еще на 2 года.

тогда как PEP 517 не указывает ничего о том, что такое бэкэнд по умолчанию

Правда. Но в какой-то момент pip откажется от специальной поддержки setuptools. В конце концов, весь смысл (по крайней мере для нас) PEP 517 состоит в том, чтобы отделить интерфейс от серверной части и уравнять все серверные части. Поэтому всякий раз, когда мы это делаем, мы должны либо выдать ошибку, если нет бэкэнда, либо выбрать значение по умолчанию (и мы перейдем к настройкам по умолчанию по причинам устаревания). Здесь спорят о том, когда мы это делаем, а не о том, если.

В настоящее время у Pip есть 2 пути кода для установки - путь PEP 517 и старый путь setup.py . Это источник проблем с обслуживанием и потенциальных ошибок. Мы решили сделать PEP 517 по умолчанию, если присутствует pyproject.toml чтобы гарантировать использование пути PEP 517 (маловероятно, что проекты будут спешить с добавлением build-backend = setuptools.buid_meta , поэтому без текущего поведения есть вероятность, что тестирование как кода PEP 517 pip, так и бэкэнда setuptools оставалось бы близким к нулю в течение длительного периода). Существует отказ в виде --no-use-pep517 именно для тех (предполагаемых редких) случаев, когда бэкэнд setuptools был неподходящим.

Я не думаю, что кто-то ожидал, что setuptools захотят иметь семантические различия между setup.py и бэкэндом, поэтому вероятность того, что --no-use-pep517 потребуется для обхода семантических различий так часто, что это должно быть дефолт даже не рассматривался.

Мы также могли бы создать "фиктивный" бэкэнд PEP 517 в инструментах настройки, таких как setuptools.build_meta_legacy, который просто chdirs в корневой каталог и вызывает setuptools.build_meta, таким образом люди могут выбрать старое поведение, только если оно им нужно, прежде чем оно начнет ломаться. .

Это может быть разумным решением. Но это должно быть хотя бы частично задокументировано - как минимум, pip документально подтвердит, что это значение по умолчанию, которое мы предполагаем. Я полагаю, что сами setuptools решили оставить бэкэнд недокументированным.

Я не уверен, насколько полезно дальнейшее теоретическое обсуждение. Я не думаю, что мне есть что добавить, конечно. Я бы посоветовал, если кто-то хочет продвинуться в этом направлении, лучшим способом было бы создать PR с переключением на значение по умолчанию, и обсуждение того, хотим ли мы принять это, может перейти к этому.

Для разработчиков пакетов, которые хотят решить эту проблему для ваших пользователей: я опубликовал прокладку, которая реализует исправление sys.path .

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

Надеюсь, это может сработать как временную ловушку, чтобы мы могли обдумать, как это следует продвигать, не торопясь с решением, или излишне замедлить внедрение pip 19.0 (который содержит гораздо больше плюсов, чем просто PEP 517).

Я опубликовал прокладку, реализующую исправление sys.path.

Это потрясающе! Независимо от окончательного исправления, это действительно хороший пример гибкости системы хуков PEP 517 :-)

Я исправил это, понизив мою версию pip до 19.x, затем я попытался установить и успешно

Есть третий вариант использования: как насчет пакетов, которые предоставляют собственный сервер сборки? Например: сам setuptools перечисляет только wheel как требование сборки:

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

Это, конечно, потерпит неудачу, если код pip для обработки PEP 517 не добавляет исходный каталог в sys.path .

С PEP 517:

При импорте пути к модулю мы не просматриваем каталог, содержащий исходное дерево, если он в любом случае не находится в sys.path (например, потому что он указан в PYTHONPATH). Хотя в некоторых ситуациях Python автоматически добавляет рабочий каталог в sys.path, это не должно повлиять на код для разрешения серверной части.

Это довольно ясно (для меня) говорит о том, что проекты не должны ожидать, что смогут увидеть свой собственный каталог проекта при разрешении build-backend - поэтому setuptools необходимо добавить себя в requires IMO. И да, я понимаю, что это происходит по кругу. Но бэкенды, которые строят сами себя, в любом случае по своей природе довольно круглые - это, конечно, не нормальный случай.

Этот же раздел, как мне кажется, подтверждает, что инструменты сборки не должны ожидать, что каталог проекта находится в sys.path среды сборки.

Как это будет работать с --no-binary :all: ?

@pfmoore Вариант ситуации: пакет предоставляет настраиваемую систему сборки. Система сборки не установлена ​​(и не является частью bdist), но поставляется с sdist, возможно, для настройки некоторого процесса сборки. Это допустимый вариант использования или сопровождающий должен опубликовать настраиваемую систему сборки как отдельный пакет?

Изменить: что-то вроде

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"]

Может быть, решением было бы добавить новую необязательную конфигурацию, чтобы указать, где найти модули во время сборки?

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

По умолчанию конфигурация имеет значение [] (пустой список), что означает, что пути не добавляются (т.е. такие же, как текущее поведение), но проекты могут добавлять пути для локального поиска системы сборки.

Если build-system полностью опущено, значение раздела по умолчанию:

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

pip может отображать предупреждение / информационное сообщение, чтобы сообщить пользователю о необходимости миграции (скорее всего, со ссылкой на страницу документации).

Дополнительным преимуществом этого решения является то, что все можно сделать в pip (на самом деле, это поставляемый модуль pep517). Ничего не нужно менять в инструментах настройки или существующих неработающих проектах.

Вариант ситуации - пакет предоставляет настраиваемую систему сборки.

Честно говоря, не знаю. Это не та ситуация, о которой я думал. Я не знаю, учли ли это авторы PEP - я не припомню, чтобы этот вопрос обсуждался, когда PEP разрабатывался.

Фактически, после проверки PEP 517 явно говорит (в разделе build-backend ): «При импорте пути к модулю мы не просматриваем каталог, содержащий дерево исходных текстов, если только он не будет в sys.path в любом случае "что на самом деле означает для меня, что явно не рекомендуется иметь внутренние серверные части. Сможет ли кто-нибудь обойти это с помощью достаточно хитрого кода, я не уверен (но подозреваю, что нет).

Ожидаемый вариант использования, когда мы разрабатывали PEP 517, заключался в том, что бэкенды будут поставляться в виде колесиков на PyPI (или настраиваемом индексе), который будет загружен и установлен в среду сборки. То, как создавались бэкенды, явно выходило за рамки - я лично предполагал, что они не будут использовать механизмы PEP 517, а будут использовать команду более низкого уровня (например, setup.py bdist_wheel или flit build ). Рекурсивное использование бэкэнда PEP 517 для создания самого себя казалось слишком сложным шагом. Это рассматривалось как часть реализации PEP 518 в pip (есть потенциальный эксплойт вилочной бомбы, если бэкэнд поставляется как sdist и использует себя для построения себя, что мы должны были предотвратить, прежде чем мы могли даже поддерживать бэкэнды, не распространяемые как колеса ), но только в контексте загрузки серверной части из PyPI.

tl; доктор Все, что я могу предложить, это мои воспоминания о дискуссиях того времени - возможно, вам лучше поискать в архивах фактическую предысторию.

Я не знаю, учли ли это авторы PEP - я не припомню, чтобы этот вопрос обсуждался, когда PEP разрабатывался.

Я только начал просматривать архивы, и, похоже, этот вопрос действительно обсуждался подробно в конце процесса (или, по крайней мере, в самом начале). Я не знаю, какой веб-сайт лучше всего подходит для просмотра архивов, но вот один момент, когда дискуссия снова начинает обсуждать этот вопрос (28 июля 2017 г.):
https://mail.python.org/pipermail/distutils-sig/2017-July/031109.html
https://www.mail-archive.com/[email protected]/msg26624.html

Например, это электронное письмо заканчивается на:

Учитывая, сколько проблем у нас уже возникло с PEP 517, было бы разумнее, чтобы PEP 517 просто требовал, чтобы каталог не находился в sys.path, и сделал небольшой дополнительный PEP только для python-path.

Я дам вам знать, если наткнусь на окончательный вердикт, но я призываю других прочитать его самостоятельно.

Ницца! Спасибо, что нашли это :-)

Я просмотрел кучу писем и думаю, что вы можете по крайней мере перейти к 29 августа, где Ник, похоже, предполагает, что существует консенсус по поводу выхода из исходного каталога _out_ sys.path:
https://mail.python.org/pipermail/distutils-sig/2017-August/031413.html
(Один за другим люди убеждались в аргументах Натаниэля.)

Тем не менее, в том же электронном письме, указанном выше, Ник говорит следующее :)

1. Если это действительно проблема, мы, вероятно, скоро узнаем, как часть реализации бэкэнда setup.py

Вот более полный абзац из письма:

Поэтому я думаю, что мы можем считать, что этот вопрос решен в пользу «Фронтенды должны гарантировать, что текущий каталог НЕ находится в sys.path перед импортом назначенного бэкэнда», поскольку запуск с этого места будет означать, что мы максимизируем наши шансы узнать что-то новое как часть начального развертывание предварительно принятого API.

Я пока не знаю, есть ли более поздние электронные письма, которые изменяют это резюме, но после этого не так много писем на эту тему.

Спасибо за просмотр архивов для нас, @cjerdonek. Заявление о моем нынешнем понимании проблемы:

1. многие реальные файлы setup.py настоящее время предполагают, что текущий каталог находится на sys.path при запуске, что создает странные проблемы с загрузкой, поскольку проекты рассматривают себя как зависимость во время установки
2. PEP 517 явно говорит, что внешние интерфейсы сборки не должны неявно добавлять текущий каталог в sys.path (он ничего не говорит о серверных модулях)
3. pip 19.0 считает pyproject.toml без раздела build-system эквивалентным разделу build-system который определяет setuptools backend
4. бэкэнд setuptools PEP 517 в настоящее время также не добавляет текущий каталог в sys.path (поскольку уход от пункта 1 выше считается желательной целью в будущем)
5. Для существующих проектов доступны два временных обходных пути, в то время как поведение по умолчанию улучшено: закрепление pip на значении меньше 19,0 и явная установка параметра --no-use-pep517 . Однако люди обнаруживают их только после того, как впервые обнаруживают, что обновление pip нарушает их сборки.

С функциональной точки зрения, я думаю, что ключевое изменение, которое мы хотим внести, заключается в том, что в случае « pyproject.toml без раздела build-system » каталог, содержащий setup.py должен оказаться на sys.path снова. Есть два основных способа справиться с этим:

1. Получите pip чтобы сделать это. Это имеет неприятный побочный эффект, заключающийся в том, что поведение внешнего интерфейса становится зависимым, и, таким образом, можно увидеть, что существующие проекты не могут быть установлены, если все внешние интерфейсы не реализуют один и тот же обходной путь.
2. Получите для этого бэкэнд setuptools PEP 517, проверив pyproject.toml предмет build-system раздела и вставив каталог setup.py в sys.path если отсутствует и раздел, и запись пути. Новый pip по-прежнему необходим в этой ситуации, так как он должен указать минимальную версию setuptools, которая правильно обрабатывает случай «no build-system section».

В интересах как можно быстрее заставить все работать для конечных пользователей, не заглядывая в какие-либо неудачные углы дизайна, я бы фактически предложил трехступенчатое разрешение:

1. Сделайте новый выпуск pip (19.0.1?), Который добавляет дополнительную запись sys.path для случая "no build-system entry". На этом этапе проблема совместимости должна в значительной степени исчезнуть для конечных пользователей.
2. Сделайте новый выпуск setuptools который обрабатывает добавление sys.path, если интерфейс еще не сделал этого.
3. В более позднем выпуске pip измените регистр «no build-system entry», чтобы исключить специальный регистр, и вместо этого установите более строгую минимальную версию для setuptools .

Это предложение основано на том факте, что я думаю, что серверная часть setuptools PEP 517 является "правильным" местом для решения проблем с обратной совместимостью setup.py , но я также считаю, что настройка pip напрямую, вероятно, будет намного более простым изменением в ближайшем будущем, и это изменение будет содержать проблему, пока работает над более предпочтительным с точки зрения архитектуры исправлением.

Я создал бэкэнд build_meta_legacy в pypa / setuptools # 1652. Я бы действительно предпочел, чтобы pip переключился на использование setuptools.build_meta_legacy в качестве бэкэнда по умолчанию, но я думаю, что создание встроенного бэкэнда «устаревшей прокладки» - это то, что мне удобно в setuptools . Я не хочу зависать на неопределенное время, поддерживая полную " python setup.py install эмуляцию" в основном бэкенде setuptools PEP 517.

Я немного смущен, почему setuptools не хочет имитировать запуск скрипта изначально здесь, TBH. Похоже, он просит конечных пользователей запутаться, когда python setup.py bdist_wheel работает правильно, а pip wheel - нет (при условии, что они установили не устаревший бэкэнд сборки).

Какое обоснование?

Какое обоснование?

Мой долгосрочный план состоит в том, чтобы отказаться от любого прямого вызова setup.py в пользу косвенного вызова с помощью внешних интерфейсов PEP 517 или чего-то эквивалентного (для других команд). Если мы переходим в мир «всех изолированных сред», я не хочу, чтобы меня заставляли поддерживать семантику вызовов команд setuptools совместимую с вызовом python setup.py , по той же причине, по которой PEP В 517 специально сказано, что фронтенды этого делать не должны - они могут нарушить изоляцию сборки и в целом создать нежелательные ситуации.

Я думаю, что это достаточно редко, кроме как части анти-паттерна. Любой, у кого есть законная потребность в этом, может довольно легко манипулировать sys.path в своем сценарии установки.

В качестве примечания, я не думаю, что PEP 517 когда-либо преследовал цель проектирования, чтобы доступ ко всем инструментам сборки был возможен через хуки. Например, у flit есть свой собственный набор команд flit build т.д., и я не знаю, чтобы отказаться от них. Так что вполне возможно, что вы можете найти крайние случаи, когда замысел PEP 517 состоял в том, чтобы использовать специфические для инструмента команды. Очевидным примером является сборка самого бэкэнда (как я упоминал выше), но существуют и другие случаи (в настоящее время не стандартизированные, хотя будущие PEP могут добавлять хуки), такие как редактируемые установки и сборки на месте (повторное использование артефактов из предыдущих сборок).

Согласиться с тем, что все инструменты могут поддерживать build sdist и build wheel, было достаточно сложно, поэтому я не думаю, что в ближайшее время произойдет дальнейшее расширение списка стандартных операций.

В качестве примечания, я не думаю, что PEP 517 когда-либо преследовал цель проектирования, чтобы доступ ко всем инструментам сборки был возможен через хуки.

Я не это предлагал, и это небольшое отступление. Я хотел сказать, что проблемы, которые требовали использования PEP 518, существуют и в более общем плане для всех команд setup.py , и их лучше всего решить, убрав людей от вызова setup.py вообще . Для этого не требуется никаких стандартов, так же как flit не нуждается в PEP для добавления подкоманд.

Ах хорошо. Извините за недопонимание.

Предлагаемый переход @ncoghlan мне кажется хорошим. Если ни у кого нет проблем с этим, давайте продолжим.

Спасибо, что откопали архивы @cjerdonek!

Учитывая, что уже есть PR, который исправляет это в setuptools (посредством введения устаревшего бэкэнда). Есть ли причина не пропустить шаг 1 выше? Мы устанавливаем инструменты установки в изолированную среду сборки, поэтому проблема не будет зависеть от самой последней версии.

Есть ли причина не пропустить шаг 1 выше?

Нет. Мы можем напрямую поднять текущую минимально необходимую версию.

Мой план перехода основан на предположении, что людям потребуется больше времени, чтобы проработать механизм долговременного перехода на стороне setuptools - в то время как выделенный переходный бэкэнд @pganssle выглядит многообещающим в этом отношении, я не уверен, что имеет смысл оставить статус-кво на месте, пока это изменение рассматривается.

Тем не менее, я не знаком с деталями того, как работает реализация PEP 517 в pip , поэтому мое предположение о том, что решение проблемы во внешнем интерфейсе будет простым, может быть неверным.

Поскольку бэкенды выполняются в подпроцессе (и фактически, используя продаваемый проект pep517 , который добавляет дополнительный уровень косвенности), мне совсем не очевидно, как мы установили sys.path для бэкэнд-крючок. Как минимум, нам нужно задействовать PYTHONPATH что означает беспокойство о случаях, когда у пользователя уже установлен PYTHONPATH , и о том, как код изоляции использует его.

По сути, установка sys.path в pip, я подозреваю, явно нетривиальна. У меня вряд ли будет время разбираться в деталях, не говоря уже о том, чтобы самому написать патч (и убедиться, что он должным образом протестирован!).

Я думаю, что получение фиксированной серверной части setuptools - это самый быстрый путь вперед.

Мой долгосрочный план состоит в том, чтобы отказаться от любого прямого вызова setup.py в пользу косвенного вызова с помощью внешних интерфейсов PEP 517 или чего-то аналогичного (для других команд).

@pganssle ой . Процедурный setup.py должен умереть. Он не должен существовать ни по какой причине. Потому что такая «гибкость» - бесконечный источник боли и поломок. Невозможно перенести setup.py и, следовательно, все проблемы с упаковкой Python.

Я бы заменил setup.py на package.json и просто добавил бы для него раздел Python вместо еще одного формата описания пакета.

По крайней мере, тогда я могу использовать спецификаторы версии ==1.x .

@techtonik Пожалуйста, уходи. Ваш неконструктивный вклад останется нежелательным для любого проекта, в котором я участвую.

Работа над # 6210 позволила мне ответить на мой собственный вопрос сверху о том, насколько сложно будет решить эту проблему на уровне pip : проблема в том, что информация о том, следует ли вставлять исходный каталог как sys.path[0] необходимо туннелировать из кода, который читает pyproject.toml до вызывающего обработчика PEP 517, а затем оттуда в фактический внутрипроцессный сценарий оболочки.

Это можно сделать без серьезных архитектурных изменений (префикс pip._implicit. в имени бэкэнда сборки для первой части и PEP517_SYS_PATH_0 env var для последней), но это означает временное изменение продаваемого pep517 пока не будет готово правильное исправление в setuptools .

Мой план перехода основан на предположении, что людям потребуется больше времени для отработки механизма долговременного перехода на стороне setuptools - в то время как выделенный переходный бэкэнд

Да, я согласен с этим. Я предложил именно это в сообщении distutils, я бы сказал, что есть две важные вещи:

1. Получение исправления для пользователей как можно скорее
2. Получение правильного перехода.

Я лично считаю, что правильным решением будет удалить логику «существование pyproject.toml позволяет вам использовать PEP 517», пока у нас не будет логики перехода. Учитывая, что изменения в setuptools имеют последствия для его общедоступного API, а в pip это просто откладывает то, что оказалось обратно несовместимым изменением, для меня имеет смысл сделайте быстрое исправление в pip пока мы рассматриваем дальнейшие шаги для setuptools .

С обоими подходами, работающими на моем локальном компьютере, я протестировал как # 6210, так и # 6212 против исходного проблемного требования PyInstaller==3.4 .

• # 6210 работал как надо: https://github.com/pypa/pip/pull/6210#issuecomment -458144828
• # 6212 работает не так, как ожидалось: https://github.com/pypa/pip/pull/6212#issuecomment -458148519

Я не знаю, является ли сбой # 6212 проблемой тестовой настройки, или, если на самом деле есть еще одна проблема в предварительной версии setuptools, я знаю только, что необходимо провести дополнительную работу по интеграции, прежде чем мы сможем быть уверены в этом решении, тогда как сейчас я уверен в # 6210 - единственное, что здесь не так, это ужасный взлом совместимости, который мы не хотим, чтобы pip носил вечно.

Похоже, что --no-cache несет ответственность за ошибку assert на # 6212. Тестирование с помощью --cache-dir вместо этого дало успешный локальный тест: https://github.com/pypa/pip/pull/6212#issuecomment -458166386

(Я собираюсь быть в автономном режиме примерно на 18 часов для сна и работы, поэтому люди могут свободно работать с любым из # 6210 или # 6212, которые имеют смысл тем временем)

Я обновил заголовок, чтобы лучше отразить ситуацию. Спасибо @ncoghlan за пиары!

Примечание модератора: я также скрыл непродуктивные комментарии (и ответы на них) как «Не по теме», и сделаю это для любых будущих комментариев по этому поводу. Если кто-то хочет обсудить модерацию, напишите новую проблему или напишите мне по электронной почте; эта ветка - не лучшее место для обсуждения любых проблем с модерацией, которые могут у вас возникнуть.

Я также пошел вперед и закрепил это, чтобы люди не создавали дубликаты и четко обозначили, что мы об этом знаем.

Даже если мы сделаем подписку на pep517, это изменение поведения, о котором не было объявлено, поэтому нарушит работу библиотек, даже если они уже выбрали подписку (см., Например, PyInstaller ). В случае, когда библиотека объявляет согласие на сборку pep517 _и_ локально импортирует вещи, которые она ожидает найти в sys.path , pip не делает никаких предположений (поскольку библиотека является явной), но библиотека все еще внезапно сломан.

В этом случае я действительно не вижу альтернативы, кроме простого включения cwd в setuptools, потому что это просто не работает. Если предложение не состоит в том, чтобы сказать людям, чтобы они вернулись и исправили выпуски, которые они прервали между pep517 и pip 19, которые, если у кого-то из пользователей будут строго закреплены эти версии, могут внезапно перестать быть устанавливаемыми, я действительно считаю, что мы должны учитывать влияние этих решений о пользовательском опыте. Основываясь на этом обсуждении и текущих предложениях, некоторые из этих библиотек не будут устанавливаться с новыми версиями pip + setuptools в будущем с использованием значений по умолчанию, если сборки pep517 не отключены явно.

Это очень важно, если вы просто пытаетесь установить пакет с помощью инструментов, предоставляемых вам Python, но на самом деле он не может устанавливать что-то случайным образом. Я говорю это, чтобы на мгновение отвлечь внимание от технических аспектов и на влияние на конечного пользователя, который может разочароваться в инструментах, экосистеме, библиотеках или самом языке, потому что внезапно (и да, только под при определенных обстоятельствах), то, что они могли установить нормально, теперь установить невозможно. Я действительно считаю, что мы должны восполнить этот пробел в любом реализованном решении.

В настоящее время мы используем стек отказов для обработки неудачных установок в pipenv, и я добавляю --no-use-pep517 когда это возможно, для обработки отказов в результате этих изменений. Я не уверен, что это будет интуитивно понятно для обычного пользователя, поскольку, вероятно, даже не сразу понятно, в чем причина проблемы. Я говорю это, чтобы указать, что у нас есть обходной путь, но мне кажется важным попытаться восполнить этот пробел, чтобы немного помочь пользователям в этом.

(править: также большое спасибо pganssle, cjerdonek, pfmoore, pradyunsg, ncoghlan и всем остальным, кто потратил кучу времени и усилий на это)

Ожидаемый вариант использования, когда мы разрабатывали PEP 517, заключался в том, что бэкенды будут поставляться как колеса на PyPI (или настраиваемом индексе), которые будут загружены и установлены в среду сборки. То, как создавались бэкенды, явно выходило за рамки - я предполагал, что они не будут использовать механизмы PEP 517, а будут использовать команду более низкого уровня (например, setup.py bdist_wheel или flit build). Рекурсивное использование бэкэнда PEP 517 для создания самого себя казалось слишком сложным шагом. Это рассматривалось как часть реализации PEP 518 в pip (есть потенциальный эксплойт вилочной бомбы, если бэкэнд поставляется как sdist и использует себя для построения себя, что мы должны были предотвратить, прежде чем мы могли даже поддерживать бэкэнды, не распространяемые как колеса ), но только в контексте загрузки серверной части из PyPI.

Просто вернемся к этому - новый setuptools.build_meta_legacy default решает проблему использования PEP 517 для всего, кроме бэкэндов PEP 517, что является проблемой для самого setuptools . Если мы этого не решим, то, как указывает @ benoit-pierre в pypa / setuptools # 1644, люди не смогут использовать pip install --no-binary :all: для любого проекта, который зависит от setuptools (или предположительно любой серверный провайдер PEP 517).

Должны ли мы обсудить это в этой ветке или создать новую ветку для обсуждения?

Должны ли мы обсудить это в этой ветке или создать новую ветку для обсуждения?

Я бы разделил это. Я сразу же чувствую, что проблема в том, что --no-binary :all: имеет здесь значительные непредвиденные последствия (на практике аналогичные влиянию использования этого флага в присутствии проекта, который только распределяет колеса, а не sdists), и я бы хотел чтобы избежать отклонений (например) о целесообразности использования --no-binary :all: дальнейшего отвлечения от этой темы.

Я не думаю, что решение проблемы с бэкэндами сборки --no-binary :all: является столь же критичным, как это. Если пользователь уже указывает --no-binary :all: , они могут относительно легко добавить --no-use-pep517 .

Новый PR №6229, который:

1. Реализует предложенный @pganssle временный обходной путь: сделать раздел build-system в pyproject.toml начальным требованием для автоматического включения в PEP 517 (отсрочка "any pyproject.toml file" opt- в более поздний выпуск)
2. Добавляет 3 специальных тестовых примера, охватывающих импорт соседнего пакета из setup.py

Я собираюсь закрыть два других PR в пользу этого, так как это минимальное исправление, которое должно заставить все снова работать для конечных пользователей и не требует каких-либо ужасных хаков, таких как # 6210, или новой версии setuptools, например # 6212

Так где же тогда setuptools.build_meta_legacy ? Предлагается ли сейчас требовать от проектов, которым требуется «импорт смежных пакетов», явно указывать это в pyproject.toml ? Если это так, я настоятельно рекомендую это где-то документировать, а также тот факт, что импорт соседних пакетов без этой спецификации устарел и будет удален в pip 19.X (нам нужно согласовать, что такое X), мы не можем это сделать программное устаревание (я не думаю), но это еще одна причина четко задокументировать это, чтобы нас не обвиняли (снова) в удалении функциональности без достаточного уведомления.

Изменить: Но в остальном спасибо за новый PR и резюме.

Изменить 2: я вижу, вы закрыли предложение setuptools.build_meta_legacy . Я не уверен, что мне это нравится, поскольку это лишает нас возможности сказать сейчас, каков наш долгосрочный план, поэтому продление любого периода прекращения поддержки, как я упоминал выше ...

@pfmoore Нет, это означает, что возвращение к желаемому поведению должно быть покрыто новой проблемой, связанной с удалением обходного пути # 6163 (возможно, путем обновления до setuptools которое предоставляет setuptools.build_meta_legacy ).

Изменить: на данный момент я только что повторно открыл # 6212, но изменил его название, чтобы прояснить, что я не думаю, что мы должны ждать завершения всего обсуждения build_meta_legacy прежде чем исправлять команды установки, которые в настоящее время не работают.

Мое предложение состояло в том, чтобы в подписке на PEP 517 указать build-system.build-backend не существование build-system вообще, и что между настоящим моментом и выпуском 19.1 setuptools добавит build_meta_legacy и pip будут использовать его как серверную часть по умолчанию.

Я согласен с тем, что в версии 19.1, вероятно, если pip не может найти setuptools.build_meta_legacy , он должен вернуться к старому пути кода. Это даст нам минимальные критические изменения при выборе максимального количества людей.

Мое предложение состояло в том, что для выбора PEP 517 указывается build-system.build-backend

... с которым можно справиться, просто установив use_pep517 = False в резервном случае (вместо того, чтобы устанавливать его на has_pyproject что мы и делаем сейчас.

в 19.1, возможно, если pip не может найти setuptools.build_meta_legacy, он должен вернуться к старому пути кода

Не думаю, что это стоит делать. Мы укажем достаточно свежую версию setuptools, и мы уверены, что получим устаревший бэкэнд, и нет необходимости учитывать возможность того, что setuptools удалит этот бэкэнд в будущей версии (или, скорее, если они это сделают, мы просто вините их в возникших проблемах ;-))

Примечание: значение по умолчанию use_pep517 = False - это то, с чего начинался # 6229, но это вызвало сбои в тестах PEP 518.

1. Случай « build-system.requires установлен» должен использовать изоляцию сборки, чтобы можно было установить запрошенные зависимости, не затрагивая родительскую среду. Самый простой способ сделать это с учетом текущей структуры кода - установить в этом случае use_pep517 = True , поэтому я сделал это и снова получил тестовый пример.
2. Отсутствующая таблица [build-system] указывает на то, что pyproject.toml просто используется для хранения настроек в таблице [tools] , так что это должно привести к use_pep517 = False чтобы быть эффективным обходным решением. для первоначально сообщенной проблемы, поэтому я отметил этот тестовый пример как ожидаемый сбой.
3. Остается случай «пустой [build-system] table», который, я думаю, может быть разрешен в любом направлении. Однако, поскольку я не думаю, что этот конкретный случай будет очень часто возникать на практике (зачем кому-то беспокоиться о добавлении таблицы build-system без установки requires или build-backend ?), Я решил разрешить это способом, который означал, что ранее определенный тестовый пример PEP 518 был пройден, а не добавлением второго маркера ожидаемого сбоя.

Чтобы разрешить 3 в другом направлении, нам нужно изменить строку:

use_pep517 = build_system is not None

вместо этого быть:

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

Таким образом, только непустые требования будут включать изоляцию сборки PEP 517 (что также означало бы добавление 4-го тестового примера, поскольку пустые и непустые поля build-system.requires теперь будут вести себя по-другому).

Извините за незваный вклад здесь, но я не могу не заметить, что все это кажется довольно сложным способом избежать того, чтобы cwd на sys.path и в конечном итоге оставит сломанные вещи, которые раньше работали, что кажется довольно разрушительным с точки зрения UX.

Это влияет на нетривиальное количество пользователей и пакетов. По крайней мере, в некоторых из них определен раздел [build-system] и _также__ полагается на старое поведение, и поэтому они останутся неработающими для всех, у кого эти версии закреплены.

@techalchemy Да, исходное предположение в pip заключалось в том, что setuptools.build_meta работает так же с точки зрения sys.path что и прямой вызов setup.py , и это предположение оказался неверным. Как только выпуск setuptools содержащий бэкэнд setuptools.build_meta_legacy определенный в https://github.com/pypa/setuptools/pull/1652, станет доступен, то # 6212 можно будет завершить, и это будет длинный срок разрешения. Однако для такого выпуска нет текущего ETA, поэтому нам нужно продолжить изучение разрешений pip -only, чтобы вернуть исходный каталог на sys.path для пакетов, которые явно не являются "родными для PEP 517". ".

В # 6229 я реализовал предложение @pganssle просто отложить принятие «PEP 517 по умолчанию», но похоже, что это вызывает больше проблем, чем решает из-за другого изменения в pip 19: обработка build-system.requires теперь привязан к обработке build-system.build-backend , поэтому --no-use-pep517 отключает PEP 518 (что вызывает сбои набора тестов, а также может вызвать сбои установки в реальном мире, если сборка зависимости не предустановлены).

В # 6210 я вместо этого локально исправляю pep517 для поддержки внедрения sys.path[0] в подпроцесс, фактически делая то же самое, что setuptools.build_meta_legacy как ожидается, сделает в будущем setutpools релиз. Похоже, что это ведет себя так, как мы хотим - build-system.requires все еще обрабатывается, а исходный каталог - sys.path[0] когда выполняется setup.py . Это также очень похоже на то, что я предложил в https://discuss.python.org/t/pep-517-backend-bootstrapping/789/29?u=ncoghlan, а @takluyver написал на https://github.com/ pypa / pep517 / pull / 42 / для обработки --no-binary :all:

Извините за то, что был самовольным RM. Произошло то, чего я не ожидал.

Я, очевидно, предпочитаю исправление на стороне setuptools, но # 6210 мне тоже подходит - как краткосрочное исправление.

Я согласен с @techalchemy и @pradyunsg - я думаю, что исправление на стороне setuptools - правильный подход. Хотя я ценю работу по поиску быстрого исправления в pip, не лучше ли потратить такое время на ускорение нового выпуска setuptools с помощью _build_meta_legacy ? Я не смотрел, что происходит в setuptools, поэтому я не совсем понимаю, почему возникает проблема с выпуском быстрого исправления в setuptools (циклы выпуска setuptools намного быстрее, чем у pip).

Я согласен с краткосрочным исправлением на стороне пипса, но я хотел бы уточнить, когда мы можем ожидать исправления setuptools.

Привет всем!

У меня та же проблема:

**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'**

Кто-нибудь знает, решена ли проблема? Или как решить временно?

Спасибо всем!

@ jce94 ,

@altendky благодарим за информацию!

Мне не удалось решить эту проблему с помощью предлагаемых обходных путей при работе с pipenv . Замораживание pip до 18.1 в Pipfile похоже, не имеет никакого эффекта, поскольку pipenv продолжает принудительно устанавливать последнюю версию пункта. Я могу вручную установить pip на 18.1, но когда я воссоздаю виртуальную среду pipenv, Pipenv будет обновляться до последней версии, несмотря ни на что ... Любые рекомендации, чтобы заставить его придерживаться?

@altendky К сожалению, использование предопределенной версии pip в то время невозможно для пользователей pipenv (а также, я думаю, для поэзии ). Оба используют последние версии. Так что я предполагаю, что многие люди пока застряли с неработающими трубопроводами

Что еще более странно, это происходит не постоянно. Я повторно выполнил задание Appveyor, первое прошло успешно, второе не удалось, хотя они полностью идентичны

Если кто-то интересуется сроками, я ожидаю, что мы сможем подготовить исправление к концу этой или в начале следующей недели и вскоре после этого выпустим следующий выпуск исправления ошибок.

Новая версия setuptools, версия 40.8.0 , теперь доступна с бэкэндом build_meta:__legacy__ .

Благодаря! И это то, что мы должны указать PyInstaller для использования? Они были
совершенно недоволен изменениями ... Любая документация или PEP, которые я могу представить
с ними, чтобы поддержать изменения?

Во вторник, 5 февраля 2019 г., 10:24 Пол Гэнссл < [email protected] написал:

Новая версия setuptools, версия 40.8.0, теперь доступна с
build_meta: __ legacy__ backend.

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/pypa/pip/issues/6163#issuecomment-460747909 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ADtXZjnOfu56IYR6VEKK4yowMg3XdcFEks5vKcxBgaJpZM4aNvmP
.

@AlmogCohen Нет, это не то, что вы должны использовать напрямую, это только для использования во внешних интерфейсах PEP 517. На следующем этапе pip начинает использовать build_meta:__legacy__ качестве бэкэнда по умолчанию. Это не требует действий с точки зрения конечного пользователя.

Есть ли ETA для нового выпуска, в который будет интегрировано исправление?

Через несколько часов. :)

См. Закрепленную проблему.

pip 19.0.2 был выпущен с исправлением для этого.

Я не могу установить pyinstaller с самой последней версией pip, даже при использовании --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\

Этот поток был автоматически заблокирован, поскольку после его закрытия в последнее время не было никаких действий. Пожалуйста, откройте новую проблему для связанных ошибок.