Pip: Ошибка с `import pip` в pip 9.0.2

Я могу подтвердить и это. Как раз собираюсь подать ту же проблему.

Это дубликат # 5079 - импорт pip не поддерживается (и никогда не был).

Да ладно.. вносить огромные изменения в одну версию x.x.PATCH ? Для метода верхнего уровня, который называется «основным»? Я думаю, что это довольно плохая форма..

Это также сломало Anaconda, и я придумал то же решение, что и @Miserlou :

https://github.com/ContinuumIO/anaconda-issues/issues/8911

Сообщается об ошибках во многих проектах.

Эта ошибка также беспокоила меня, когда я пытался использовать pip для обновления своего anaconda-navigator.

Есть ли шанс, что мы получим версию 9.0.3, в которой это исправлено — в идеале, довольно скоро?

Это уже затрагивает множество крупных проектов (Anaconda, SpaCy, Zappa), и только на GitHub существует более 850 000 использований этого , которые теперь нарушены этим предполагаемым обновлением «патча».

Можете ли вы хотя бы отменить это масштабное изменение в версии 9.0.3, а затем _объявить_ нижестоящим пользователям о своем намерении изменить это поведение для будущего выпуска 10.xx или, по крайней мере, 9.xx?

Мы также не хотим использовать более старую версию, но именно это мы и сделали. 9.0.2 не существует в нашей среде CI, по крайней мере, на данный момент.

Также наблюдается этот хит в некоторых проектах OpenStack.

Pip 10 должен выйти примерно через месяц. Насколько я понимаю, проблема связана с кодом, который использует import pip для доступа к внутренним функциям pip. Мы никогда официально не поддерживали такое использование, и мы явно задокументировали это отсутствие поддержки в течение некоторого времени (хотя и только в «последней» версии документации по адресу https://pip.pypa.io/en/latest/user_guide). /#using-pip-from-your-program, потому что у нас не было новой стабильной версии с тех пор, как был добавлен этот раздел документации). Мы также объявили о внутренней реорганизации, чтобы прояснить, что использование внутренних API не поддерживается, в октябре прошлого года (см. https://mail.python.org/pipermail/distutils-sig/2017-October/031642.html). Это изменение, которое находится в пункте 10, нарушит любое такое использование независимо от того, какой пункт будет выполнять возможный выпуск пункта 9.0.3. Так что трудно рассматривать это как внезапную, неожиданную поломку.

Если @dstufft хочет выпустить экстренный выпуск 9.0.3, я не против. Но это будет только очень краткосрочная выгода, и я немного разочарован тем, что люди еще не отошли от import pip . Людям, затронутым этой проблемой, все равно нужно будет подготовиться к 10-му пункту, и они должны понимать, что простой переход на import pip._internal — это не то, что мы поддерживаем или рекомендуем.

Предложения о повторном введении некоторого уровня поддержки API, безусловно, являются вариантом (см., например, # 5080), но на данном этапе уже слишком поздно для любых таких изменений, чтобы сделать их 10-м пунктом.

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

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

К сожалению, это масштабное изменение появилось в обновлении PATCH , которое _должно исправлять, а не ломать_. Это полная противоположность семантической версии. И в результате мы наблюдаем огромный ущерб всей экосистеме Python.

Вы должны отменить это изменение как можно скорее в другом обновлении PATCH , а затем внести серьезное критическое изменение в обновление версии MAJOR . Теперь, когда вы уже преждевременно сломали все для всех, я думаю, они будут лучше осведомлены о грядущих серьезных изменениях.

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

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

@Miserlou Хорошо, я понимаю вашу точку зрения - мы нацелились на внутреннее изменение переименования для пункта 10, потому что это основная версия. Я действительно не знаю драйверы для выпуска патча - @dstufft сообщил мне об этом, и, по-видимому, это сделано для того, чтобы избежать значительных поломок для пользователей Mac OS, когда нас настигнет неизбежный крайний срок для поддержки TLS, то есть до выпуска 10-го пункта. Мы ожидали, что проблемы будут достаточно значительными, чтобы оправдать краткосрочный выпуск исправлений. Конечно, не было намерения нарушать существующее использование.

Я должен передать решение о продолжении 9.0.3 @dstufft - у меня нет подробностей о том, что вошло в 9.0.2, и не знаю, возможно ли вообще определить, как решить эту проблему. И я не могу судить, принесет ли отказ от 9.0.2 общее преимущество, так как понятия не имею, сколько людей затронуто проблемой Mac OS. Я понимаю, что (по крайней мере, для некоторых людей) закрепление на 9.0.1 — это решение, так что это может оказаться наименее плохим вариантом.

Проблема macOS TLS затронет всех, кто использует системный Python на macOS <10.13.

Я должен оставить решение о продолжении 9.0.3 @dstufft

Я того же мнения, что и @pfmoore.

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

Та же проблема с pip 9.0.2 в gitlab-ci с docker python 3.4: KeyError

  File "/usr/local/lib/python3.4/site-packages/pip/__init__.py", line 45, in <module>
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/usr/local/lib/python3.4/site-packages/pip/vcs/mercurial.py", line 9, in <module>
    from pip.download import path_to_url
  File "/usr/local/lib/python3.4/site-packages/pip/download.py", line 40, in <module>
    from pip._vendor import requests, six
  File "/usr/local/lib/python3.4/site-packages/pip/_vendor/requests/__init__.py", line 98, in <module>
    from . import packages
  File "/usr/local/lib/python3.4/site-packages/pip/_vendor/requests/packages.py", line 12, in <module>
    sys.modules['pip._vendor.requests.packages.' + mod] = sys.modules["pip._vendor." + mod]
KeyError: 'pip._vendor.urllib3.contrib'

К вашему сведению, 9.0.2 был выпущен с неработающими сборками:

Ссылка на Travis-CI: https://travis-ci.org/pypa/pip/builds/354616774?utm_source=github_status&utm_medium=notification

Конечно, ошибки могут быть не связаны, хотя это просто пахнет "поспешным выпуском"...

@pfmoore

Если @dstufft хочет выпустить экстренный выпуск 9.0.3, я не против. Но это будет только очень краткосрочная выгода, и я немного разочарован тем, что люди еще не отошли от импортных пипсов. Людям, затронутым этой проблемой, все равно нужно будет подготовиться к 10-му пункту, и они должны понимать, что простое переключение на import pip._internal — это не то, что мы поддерживаем или рекомендуем.

Я не могу поверить, что это заявление владельца этого репозитория... Вы буквально только что сказали "к черту семантическое управление версиями" и "кому вообще нужна политика устаревания".

pip всегда документировался как НЕ имеющий расходуемого Python API, я разочарован людьми, которые даже в этот момент пытаются изменить карму «говорил вам так уже несколько лет»

@RonnyPfannschmidt Это все равно, что сказать: «Мы сто раз говорили вам, что вам нельзя превышать ограничение скорости», а затем ввести ограничение скорости, заменив все автомобили с двигателями автомобилями из кремня, чтобы люди не могли превышать ограничение скорости больше.

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

что просто обвиняешь, потому что не любишь быть виноватым

@РонниПфанншмидт

что просто обвиняешь, потому что не любишь быть виноватым

Итак, вы говорите, что я виноват в использовании сторонних пакетов, которые полагаются на недокументированную функцию pip. Может быть, я ... Я должен был проверить эти сторонние пакеты на наличие этих ошибок и отправить сообщение о проблеме или, что еще лучше, PR.

Но давайте смотреть правде в глаза: существует множество проектов, которые сейчас используются в продакшне, но не работают. Это не вопрос морали, не вопрос, чья это вина. Это вопрос «не могли бы вы исправить это и предоставить надлежащее предупреждение / устаревание».

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

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

@anx-ckreuzberger

Я не могу поверить, что это заявление владельца этого репозитория... Вы буквально только что сказали "к черту семантическое управление версиями" и "кому вообще нужна политика устаревания".

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

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

1. Указатель на заявление любого из сопровождающих pip о том, что мы поддерживаем использование внутреннего API pip в пользовательском коде.
2. Указатель на заявление любого из сопровождающих pip о том, что pip использует семантическое управление версиями.

Не думаю, что вы найдете доказательства...

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

Нет, но обвинять мейнтейнеров pip, а не эти проекты, неприемлемо. Мы пытаемся помочь вам, но не можем нести ответственность за то, что делают эти проекты. Поделитесь с ними своими обидами.

Но давайте смотреть правде в глаза: существует множество проектов, которые сейчас используются в продакшне, но не работают. Это не вопрос морали, не вопрос, чья это вина. Это вопрос «не могли бы вы исправить это и предоставить надлежащее предупреждение / устаревание».

Мы попытались сделать предупреждение. Несколько месяцев назад мы разослали объявления, добавили документы, объясняющие ситуацию, и постоянно отвечали на вопросы трекера о том, что использование внутренних API не поддерживается. Добавление устаревания далеко не так просто, как вы предлагаете, поскольку сам pip будет извергать эти предупреждения (или у pip будет способ их отключить, который другие просто скопируют - мы уже слышим о людях, планирующих просто import pip._internal , так что даже это изменение их не остановит :disappointed:).

Что касается «исправления», я с радостью признаю, что 9.0.2 был выпущен быстро для решения насущной проблемы, и мы не ожидали этой проблемы. Возможно, выпуск версии 9.0.3 со сроком жизни 2-3 недели будет разумным решением, я сам так не думаю, но я сказал, что мы это рассмотрим. Я лично не могу согласиться на это, так как я не занимаюсь выпуском 9.0.x. Я работаю над пунктом 10, который сделает все эти дебаты неактуальными, так что это, вероятно, мое последнее слово по этому вопросу — мне нужно сосредоточиться на вещах, связанных с этим релизом.

Мой личный совет:

1. Привяжите к 9.0.1, если это вас затронет и вам нужен обходной путь сейчас .
2. Будьте готовы к пункту 10, когда все зависимости, которые у вас есть в настоящее время, которые сломаны, потому что они используют внутренние API-интерфейсы пункта, снова сломаются. Подтолкните эти зависимости, чтобы принять меры в соответствии с информацией, которую мы давали в течение нескольких месяцев, и радуйтесь, что вы получили заблаговременное предупреждение о том, что это произойдет.
3. Если будет выпущен пункт 9.0.3, удалите булавку.
4. Пожалуйста , протестируйте бета-версию pip 10, когда она выйдет, и сообщите о любых проблемах соответствующим сторонам (сторонние проекты, если они звонят pip внутренне, нам, если вы сами звоните pip).

У меня возникла такая же проблема с pip 9.0.2 и Python 2.7.14 в контейнере докера.
Однако я не могу воспроизвести проблему на моей машине разработки вне контейнера докеров.
Я искал импорт пипсов (grep'd для import.pip , from.pip , \'pip , \"pip ), но ничего не смог найти.
Мы в Plone используем механизм для автоматического включения конфигураций из пакетов, включенных в файл setuptools setup.py, что звучит подозрительно, но опять же — здесь используется просто __import__ и nothign из pip AFAIcansee.

Это соответствующая часть трассировки:

  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/xmlconfig.py", line 359, in endElementNS
    self.context.end()
  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/config.py", line 558, in end
    self.stack.pop().finish()
  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/config.py", line 706, in finish
    actions = self.handler(context, **args)
  File "/home/plone/.buildout/shared-eggs/z3c.autoinclude-0.3.7-py2.7.egg/z3c/autoinclude/zcml.py", line 51, in includeDependenciesDirective
    info = DependencyFinder(dist).includableInfo(['configure.zcml', 'meta.zcml'])
  File "/home/plone/.buildout/shared-eggs/z3c.autoinclude-0.3.7-py2.7.egg/z3c/autoinclude/dependency.py", line 26, in includableInfo
    module = resolve(dotted_name)
  File "/home/plone/.buildout/shared-eggs/zope.dottedname-4.2-py2.7.egg/zope/dottedname/resolve.py", line 39, in resolve
    found = __import__(used)
  File "/plone/buildout/lib/python2.7/site-packages/pip/__init__.py", line 45, in <module>
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/plone/buildout/lib/python2.7/site-packages/pip/vcs/mercurial.py", line 9, in <module>
    from pip.download import path_to_url
  File "/plone/buildout/lib/python2.7/site-packages/pip/download.py", line 40, in <module>
    from pip._vendor import requests, six
  File "/plone/buildout/lib/python2.7/site-packages/pip/_vendor/requests/__init__.py", line 98, in <module>
    from . import packages
  File "/plone/buildout/lib/python2.7/site-packages/pip/_vendor/requests/packages.py", line 12, in <module>
    sys.modules['pip._vendor.requests.packages.' + mod] = sys.modules["pip._vendor." + mod]
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/plone/buildout/parts/instance/etc/site.zcml", line 15.2-15.55
    ZopeXMLConfigurationError: File "/plone/buildout/parts/instance/etc/package-includes/002-bda.aaf.site-configure.zcml", line 1.0-1.56
    ZopeXMLConfigurationError: File "/plone/buildout/src-aaf/bda.aaf.site/src/bda/aaf/site/configure.zcml", line 11.2-11.48
    ZopeXMLConfigurationError: File "/plone/buildout/src-aaf/bda.aaf.site/src/bda/aaf/site/configure-dependencies.zcml", line 10.2-10.39
    ZopeXMLConfigurationError: File "/plone/buildout/src-addons/plone.app.mosaic/src/plone/app/mosaic/configure.zcml", line 9.2-9.39
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/plone.app.tiles-3.0.3-py2.7.egg/plone/app/tiles/configure.zcml", line 18.2-18.41
    ZopeXMLConfigurationError: File "/plone/buildout/src/plone.app.z3cform/plone/app/z3cform/configure.zcml", line 10.2-10.41
    ZopeXMLConfigurationError: File "/plone/buildout/src/plone.app.widgets/plone/app/widgets/configure.zcml", line 12.2-12.41
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/Products.CMFPlone-5.1.0.1-py2.7.egg/Products/CMFPlone/configure.zcml", line 15.2-15.46
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/plone.app.contenttypes-1.4.9-py2.7.egg/plone/app/contenttypes/configure.zcml", line 10.2-10.37
    KeyError: 'pip._vendor.urllib3.contrib'

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

Подумайте об этом так: pip — это утилита командной строки, а не библиотека. Тот факт, что он написан на Python, значения не имеет. Такова реальность.

@pfmoore

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

Подумайте об этом так: pip — это утилита командной строки, а не библиотека. Тот факт, что он написан на Python, значения не имеет. Такова реальность.

Суть в том, что на самом деле не имеет значения, что вы обещали. Важно то, что вы сделали и какова результирующая ситуация. Возможно, вы думали об этом как об утилите командной строки. Но вы выпустили его как библиотеку. Такова реальность вопроса:

Вы выпустили библиотеку с функцией X. Люди начали использовать функцию X. Конечно, вы сказали: «Ребята, пожалуйста, не используйте функцию X». Но вы продолжали выпускать его с Feature X. Годами. И поэтому люди продолжали его использовать. Десятки, может быть, сотни, тысячи проектов, больших и малых, используют его сейчас. Вдруг вы удалите его в минорном обновлении без надлежащего предупреждения.

Как вы думаете, что произойдет дальше?

В краткосрочной перспективе люди просто закрепят старую версию и не открепят ее, если на это нет веской причины.

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

@pfmoore вы видите что-то подозрительное в трассировке, на которую я ссылался выше? AFAIK не использует никаких внутренних элементов пипса. Интересно, что у большинства людей есть эти проблемы в контейнерах докеров.

@ все, обвинение сопровождающих в неработающем коде не помогает решить проблему.

Подумайте об этом так: pip — это утилита командной строки, а не библиотека. Тот факт, что он написан на Python, значения не имеет. Такова реальность.

Факт: Его нельзя импортировать, если импортировать даже с помощью автопроверки кода по какой-то причине: все ломается. Я предполагаю, что это происходит в случае с @thet .
Вывод: pip должен изолировать себя от глобального или текущего пространства имен virtualenv/venv Python, в которое он устанавливает пакеты. Таким образом, он не загрязняет его, и даже случайный импорт не происходит.

Прежде всего, извините, если я обвинил сопровождающих репо в ошибочном коде. Любые обвинения были сделаны из-за разочарования и, если вообще, указывают на тот факт, что ИМХО выпуск 9.0.2 по определению semver является патч-релизом (хотя @pfmoore ясно дал понять, что pip не обязательно использует semver - что это еще одна проблема для другого дня, я думаю).

@МайкХарт85

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

Довольно много. Я имею в виду менеджеры пакетов JavaScript: npm, bower, yarn, все, что будет выпущено в следующем ~году~ неделе.

Нет, но обвинять мейнтейнеров pip, а не эти проекты, неприемлемо. Мы пытаемся помочь вам, но не можем нести ответственность за то, что делают эти проекты. Поделитесь с ними своими обидами.

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

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

Это было для пункта 9.0.2 или для пункта 10? Если бы это было для pip 9.0.2, мне было бы неплохо, если бы в журнале изменений была заметка. В любом случае, спасибо за то, что вы очень активно участвовали в разработке пункта 10 и рассылали объявления о том, что не используете import pip , это хорошо! Так держать!

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

Я не думаю, что это будет слишком сложно... У вас уже есть это в __init__.py :

if __name__ == '__main__':
    sys.exit(main())

Как насчет того, чтобы просто добавить еще?

if __name__ == '__main__':
    sys.exit(main())
else:
    logger.warning("You are importing PIP as a Python library. This behaviour is deprecated and should no longer be used. We will break the API with version 10.0!!!111eleven Please see https://pip.readthedocs.org/some_link_where_you_explain_this.html")

edit : вы даже можете создать исключение здесь, если хотите быть «строгим» в этом отношении, и добавить аналогичные операторы в подмодули.

То, что люди будут обходить это, — это нечто другое. Если вы хотите взломать библиотеку, вы всегда можете перепроектировать ее. Всегда можно найти обходной путь. Но вы не должны рассматривать все способы обойти это в своих дизайнерских решениях.

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

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

Важно сохранять чувство перспективы в отношении этих вещей. Есть.. меньше 15? 20? люди комментируют, как это их сломало (хотя с этими показателями всегда есть проблема «верхушки айсберга»), между тем pip 9.0.2 уже является вторым наиболее часто используемым установщиком на прошлой неделе (считая дни, когда он даже не существовал) for) и загрузил 17 миллионов файлов из PyPI с момента его выпуска. Глядя только на последний день, это 80% пути к тому, чтобы обогнать pip 9.0.1 как наиболее часто используемый установщик на PyPI.

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

ЕСЛИ я смогу найти время, я могу попытаться вырезать 9.0.3, в первую очередь, чтобы решить случай, с которым @thet столкнулся, когда это просто автоматический импортер, пытающийся импортировать вещи, и они на самом деле не пытаются использовать внутренние API-интерфейсы pip каким-либо образом. Если это также приведет к разрешению поведения людей, использующих внутренние API-интерфейсы pip, я не собираюсь изо всех сил ломать их конкретно, но если это не так, я также не собираюсь изо всех сил исправлять конкретно их тоже.

Пожалуйста, обратите внимание, что на данный момент выпуск версии 9.0.x занимает много часов (все разошлось в master настолько, что для выпуска версии требуется некоторая ловкость), и это не считая времени, необходимого для отладки. и исправить фактическую проблему. Если вы хотите увеличить вероятность того, что это произойдет, отладка, исправление и предоставление патча (или ответвления от тега 9.0.2 в вашем собственном форке) — лучший способ сделать это.

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

Спасибо. Разочарование здесь велико, и я это понимаю.

Как насчет того, чтобы просто добавить еще?

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

Это было для пункта 9.0.2 или для пункта 10?

Для 10.0. Изначально не было намерения выпускать 9.0.2, мы сделали это только в качестве экстренного выпуска, чтобы пользователи Mac OS не потеряли весь доступ к PyPI, когда изменения TLS вступят в силу.

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

Я всегда нахожу эту "угрозу" забавной.

Это вообще не угроза, извините, если так показалось.

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

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

Альтернативы - это не всегда хорошо. Они склонны делать вещи грязными. Лично я бы предпочел один менеджер пакетов. За все. Но я соглашусь на единый менеджер пакетов для Python.

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

Привет, @dstufft , спасибо за участие. Эта тема становится довольно горячей!

Прежде всего, я благодарю вас за вашу работу! Я знаю, что техническое обслуживание — это бесконечная и неблагодарная работа, и я полагаю, что она становится только хуже, когда вы управляете таким большим и популярным проектом, как pip !

Теперь о проблеме: несмотря на то, что об этой проблеме уже сообщили двадцать _сопровождающих_, я знаю, что она уже затрагивает тысячи _людей_ — некоторые из затронутых проектов сами по себе огромны: Anaconda, OpenStack, SpaCy, Zappa и многие десятки тысяч пользователей. Я знаю, что наш канал в Slack переполнен обсуждениями по этому поводу. (Буквально, пока я печатал это, появился новый выпуск.)

Ясно, что есть много важных проектов Python, которым нужна возможность программно проверять свою среду. Это вполне разумная вещь, которую нужно уметь делать. Кроме того, документация никогда не предостерегала от этого — и до сих пор не предостерегает! (Нажмите ссылку «Документы» в файле README этого репозитория!)

Я думаю, что ситуация на данный момент такова:

• Учитывая формат строки версии, мы все полагали, что сопровождающие pip следуют семантическому управлению версиями.
• Мейнтейнеры pip выпустили «патч», в котором были внесены серьезные изменения.
• Это изменение было необъявленным и незадокументированным — и я полагаю, неожиданным и непреднамеренным.
• Теперь простой вызов import pip немедленно ломает программу, которая крайне враждебна разработчикам.
• Это вызывает серьезные проблемы во всей экосистеме Python.
• В документации нет (и _до сих пор_ нет — щелкните ссылку «Документы» в файле README этого репозитория) предупреждения об использовании pip программно.
• Не было объявления о том, что import pip вызовет этот ущерб в обновлении PATCH — это объявление было сделано для версии, которая _еще не выпущена_.
• Это изменение даже не было упомянуто в журнале изменений.
• Мы не хотим заменять pip или разработчиков pip! Мы тебя любим!
• ... но мы не хотим, чтобы подобное повторилось!
• ..поэтому мы хотим, чтобы за Семвером следили!
• Нам бы очень, очень хотелось еще PATCH , которая отменяет это серьезное изменение!

Потребность в программном способе проверки среды в мире pip >= 10.0.0 — это тема для другого обсуждения, но суть дела в том, что нам никогда не говорили, что мы не должны программно использовать pip в pip. <=9 мир, и произошло масштабное, необъявленное изменение, и мы бы очень-очень хотели, чтобы оно было отменено, потому что оно негативно влияет на тысячи людей.

Еще раз спасибо,
Богатый

Прежде всего: спасибо мейнтейнерам pip за их усилия и идеи в рамках проекта. Я считаю, что это действительно помогает другим понять проблему (хотя, возможно, стоит написать об этом сводную статью в блоге).

@dstufft

Важно сохранять чувство перспективы в отношении этих вещей. Есть.. меньше 15? 20? люди комментируют, как это их сломало (хотя с этими показателями всегда есть проблема «верхушки айсберга»), между тем pip 9.0.2 уже является вторым наиболее часто используемым установщиком на прошлой неделе (считая дни, когда он даже не существовал) for) и загрузил 17 миллионов файлов из PyPI с момента его выпуска. Глядя только на последний день, это 80% пути к тому, чтобы обогнать pip 9.0.1 как наиболее часто используемый установщик на PyPI.

Я почти уверен, что эта метрика сильно искажена всеми автоматизированными командами pip install pip --upgrade из систем непрерывной интеграции/доставки (они должны использовать кеши и, следовательно, не должны постоянно переустанавливать пакеты из pypi; но в при этом тоже не стоит делать import pip ... так устроен мир айтишников).

Тот факт, что (менее) 15 человек пожаловались на это, должен говорить о двух вещах:

1. Я не думаю, что многие люди используют 9.0.2 (в производстве), некоторые могут все еще пытаться отладить эту проблему и будут «временно» исправлять ее, используя вместо этого pip 9.0.1, пока она не будет решена (или навсегда .. .) - также некоторые люди могли не заметить, что что-то еще не работает...
2. Уже через 2 дня после релиза об этом говорят люди. С этой проблемой столкнется больше людей. Подождите 2 недели, и в итоге 100 человек пожалуются на это (например, когда они закончат спринт и отправятся в QA/staging). На данный момент вы действительно не знаете, сколько людей затронет это изменение.

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

Ясно, что есть много важных проектов Python, которым нужна возможность программно проверять свою среду. Это вполне разумная вещь, которую нужно уметь делать. Кроме того, документация никогда не предостерегала от этого — и до сих пор не предостерегает! (Нажмите ссылку «Документы» в файле README этого репозитория!)

Мне непонятно, почему вы должны предостерегать от этого. Использование pip как инструмента командной строки полностью недокументировано . При поиске в документации я вообще не вижу ссылок на import pip . Это похоже на жалобу, потому что вы связались с некоторыми .so , используемыми Chrome, и они нарушили совместимость с ABI.

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

Реверсировать действительно нечего. Исправления обратной переносимости для предотвращения невозможности доступа значительной части пользователей macOS к PyPI в ближайшем будущем имеют ошибку при применении к кодовой базе 9.0.x, которая проявляется только в неподдерживаемых условиях. Единственный путь вперед — проделать дополнительную работу по устранению этой ошибки в серии 9.0.x. Как я уже сказал, если я найду время, я попытаюсь это сделать, если вы хотите увеличить вероятность того, что это произойдет, предоставьте патч.

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

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

отправлено из моего Айфона

20 марта 2018 г., в 11:02, Rich [email protected] написал:

Привет, @dstufft , спасибо за участие. Эта тема становится довольно горячей!

Прежде всего, я благодарю вас за вашу работу! Я знаю, что поддержка — это бесконечная и неблагодарная работа, и я думаю, что она становится только хуже, когда вы управляете таким большим и популярным проектом, как pip!

Теперь к обсуждаемому вопросу: хотя об этой проблеме до сих пор сообщили двадцать специалистов по сопровождению, я знаю, что она уже затрагивает тысячи людей — некоторые из затронутых проектов сами по себе огромны: Anaconda, OpenStack, SpaCy, Zappa и многие десятки тысяч пользователей. Я знаю, что наш канал в Slack переполнен обсуждениями по этому поводу. (Буквально, пока я печатал это, появился новый выпуск.)

Ясно, что есть много важных проектов Python, которым нужна возможность программно проверять свою среду. Это вполне разумная вещь, которую нужно уметь делать. Кроме того, документация никогда не предостерегала от этого — и до сих пор не предостерегает!

Я думаю, что ситуация на данный момент такова:

Учитывая формат строки версии, мы все полагали, что сопровождающие pip следуют семантическому управлению версиями.
Мейнтейнеры pip выпустили «патч», в котором были внесены серьезные изменения.
Это изменение было необъявленным и незадокументированным — и я полагаю, неожиданным и непреднамеренным.
Теперь простой вызов import pip немедленно ломает программу, которая крайне враждебна разработчикам.
Это вызывает серьезные проблемы во всей экосистеме Python.
В документации нет (и до сих пор нет — щелкните ссылку «Документы» в README этого репозитория) предостережения против программного использования pip.
Не было объявления о том, что import pip вызовет этот ущерб в обновлении PATCH — это объявление было сделано для версии, которая еще не была выпущена.
Это изменение даже не было упомянуто в журнале изменений.
Мы не хотим заменять pip или разработчиков pip! Мы тебя любим!
... но мы не хотим, чтобы подобное повторилось!
..поэтому мы хотим, чтобы за Семвером следили!
Мы бы очень, очень хотели еще один ПАТЧ, который отменяет это серьезное критическое изменение!
Потребность в программном способе проверки среды в мире pip >= 10.0.0 — это тема для другого обсуждения, но суть дела в том, что нам никогда не говорили, что мы не должны программно использовать pip в pip. <=9 мир, и произошло масштабное, необъявленное изменение, и мы бы очень-очень хотели, чтобы оно было отменено, потому что оно негативно влияет на тысячи людей.

Еще раз спасибо,
Богатый

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите ветку.

@Miserlou

Учитывая формат строки версии, мы все полагали, что сопровождающие pip следуют семантическому управлению версиями.

Как человек, который категорически против semver, можете ли вы сообщить мне, в каком формате должны быть строки моей версии, чтобы устранить эту путаницу? «Числа с тремя точками» не означает для меня «строго следует semver», поэтому это предположение стало неожиданностью.

В ответ на этот комментарий : Независимо от того, придерживается ли pip semver или обещает придерживаться его, использование схемы управления версиями major.minor.micro по-прежнему несет в себе неявное обещание некоторого ограничения в отношении микровыпусков. Если пин-кода совместимого выпуска , такого как ~= 9.0.1 , недостаточно для защиты пользователей от неожиданных нарушений обратной совместимости, остается единственная безопасная альтернатива — простое сопоставление версий . Если нет намерения поддерживать что-то большее, чем сопоставление версий, то pip может также переключиться на схему версий в стиле Chrome, которая имеет только один монотонно увеличивающийся компонент.

Редактировать: я вижу, что @dstufft уже предложил двигаться в этом направлении, приняв версии на основе даты. Я думаю, что это был бы прискорбный побочный ущерб в результате этого инцидента.

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

Кроме того, я могу воспроизвести это в virtualenv (2 или 3, это не имеет значения) со следующими шагами:

virtualenv -p python3 /tmp/pip
/tmp/pip/bin/pip install -e path/to/clone/of/pip/9.0.2
/tmp/pip/bin/pip install requests
/tmp/pip/bin/python

Затем в оболочке Python:

>>> import requests
>>> import pip

Если запросы еще не были импортированы, import pip завершается успешно.

неожиданные перерывы в обратной совместимости

Пожалуйста, укажите мне, где import pip был задокументирован как стабильный API, который подпадает под наши обещания обратной совместимости? Я хотел бы убедиться, что удалю такую ​​документацию, поскольку мы категорически не поддерживаем такое использование.

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

pip — менеджер пакетов Python. Python — это язык программирования. Людям необходимо проверять свою среду программно. 1+1=2.

Для людей было совершенно разумным предположить, что это был правильный способ сделать это. В документации не было - и _ до сих пор нет _ - ничего, говорящего _не_ делать это. Напоминаем, что более 700 000 заявок пришли к такому же выводу ! Кроме того - нет другого способа сделать это!

Тот факт, что что-то не задокументировано в ReadTheDocs, не означает, что это запрещено — все мы каждый день сталкиваемся и используем проекты, которые просто предоставляют код таким образом.

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

Кроме того, мы не говорим о частных API с пространством имен _ , как это принято, или даже о каком-либо конкретном общедоступном методе, мы говорим только о _простом вызове import_, который вызывает этот катастрофический сбой.

В документации не было - и до сих пор нет - ничего, что запрещало бы это делать.

https://pip.pypa.io/en/latest/user_guide/#using -pip-from-your-program

Если вы нажмете на ссылку «Документы» _этого самого репозитория_, вы не попадете на эту страницу. Никто не ссылается на последние. Ваши собственные ссылки на документацию не ссылаются на последнюю версию. Нет возможности попасть на эту страницу. Все идет в стабильную, в которую не входит тот раздел.

@Miserlou Я думаю, что это примечание — любезность для людей, которые почему-то думают, что им следует импортировать внутренности инструмента командной строки только потому, что он реализован на Python, и эти внутренности можно импортировать.

Я понимаю, что у вас другая интерпретация общедоступного интерфейса pip , чем у меня, разработчиков и большинства людей, которые думают о pip как о CLI-программе, но каков реальный вред от этого? Просто закрепите pip != 9.0.2 и покончите с этим.

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

Честно говоря, сопровождающие pip уже заявили, что, если позволит время, они попытаются исправить эту проблему, хотя всем рекомендуется отправить запрос на включение, чтобы ускорить процесс.

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

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

• Адекватное описание проблемы.
• Возможные обходные пути, которые кто-то может использовать, если они столкнутся с этим.
• Обоснование того, почему мы не считаем это критическим изменением в соответствии с нашими рекомендациями по обратной совместимости.
• Заявление о том, что я постараюсь найти время, чтобы это исправить (правда, никаких обещаний по этому поводу).
• Призыв к действию, который можно сделать, если кто-то, затронутый этим, хочет повысить вероятность существования 9.0.3 с исправлением.

На данный момент дискуссия не имеет реальной цели, кроме дальнейшего разочарования всех участников, поэтому я пока отказываюсь от этой темы. Этот вопрос будет закрыт либо при выпуске 10.0, либо 9.0.3. Если кто-то действительно приложил усилия к призыву к действию, он может либо открыть запрос на включение, либо отправить diff по этой проблеме.

Чтобы сделать эту мантру «не импортировать пип» более заметной, как насчет переименования пространства имен в «_pip». Это указывает на то, что целое не предназначено для публичного использования на уровне имени.
Кроме того, было бы проще указать коду автоматической проверки не смотреть на вещи, начинающиеся с подчеркивания. Что ж, последнее также потребует изменений в кодексе проверки участия. Но, по крайней мере, есть возможность автоматизировать его (по соглашению) без управления черными списками.

Хорошо, последнее, что я клянусь - пункт 10 уже переместил весь соответствующий код в pip._internal (мы не использовали _pip , потому что это сломало бы python -m pip , который поддерживается).

Может ли кто-нибудь проверить, решает ли https://github.com/pypa/pip/pull/5100 это для них?

Сотрите это, я думаю, что # 5100 неверен, не могли бы вы вместо этого проверить https://github.com/pypa/pip/pull/5101 , пожалуйста.

@dstufft Я могу подтвердить, исправление в # 5101 решает проблему для меня.

Спасибо @dstufft за то, что уделили этому время. Я буду работать с командами Anaconda, чтобы сообщить об этой проблеме и помочь им отказаться от импорта pip.

Для записи в этой теме # 5101 также решил мою проблему.

То же самое, #5101 позволяет импорту работать внутри нашего инструмента. Предупреждение: я не тестировал ни исправленную точку, ни наш инструмент.

Это должно быть исправлено в 9.0.3.

Спасибо за быстрое решение от человека, который никогда в жизни не писал import pip , но был потребителем пакета, который это сделал. После прочтения этой ветки создается впечатление, что многие приложения импортировали pip, неосознанно вопреки передовым методам, и многие разработчики и пользователи потенциально подвержены влиянию v9.0.2 и v10.

Я второй/третий/N-й добавил надлежащее предупреждение об устаревании, чтобы сделать все более плавным. может быть, даже сообщение pypi.python.org?

Ура! Спасибо за это!

Мне также очень понравилось бы предупреждение об устаревании и, что более важно, правильные инструкции о том, как программно проверять среды Python в мире pip10! Очевидно, что в этом есть необходимость, учитывая, что эта ошибка затронула более 700 000 приложений .

pip list --format=json ?

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

Из-за этого «на удивление широко распространенного и полезного неопределенного поведения» нам нужно сделать piplib как libgit2 для git? Обратите внимание, что libgit2 не делится кодом с git и поддерживается другой группой из git. И это хорошо для экосистемы git. Возможно, piplib охватит некоторые интересные варианты использования, которых мы не ожидали.

Вот похожая история: https://public-inbox.org/git/1267957655.3759.29.camel@mattotaupa/T/

@drunkwcodes Я подозреваю, что то, что вы предлагаете, уже реализовано в существующих пакетах, которые упоминаются в документации по pip, packaging , setuptools и distlib . Насколько я могу судить из этой ветки, проблем с пробелами в функциональности нет, но у некоторых людей возникают проблемы с инструментами, которые пытаются импортировать и проверять каждый модуль, и рассматривают сбои импорта как фатальные ошибки.

Мне кажется, что такие инструменты могут обойти эту проблему, заключая операторы импорта в блок try/except, но это также кажется сомнительным прецедентом. Однако, учитывая выпуск pip 9.0.3, я думаю, что, вероятно, не стоит тратить время на обсуждение проблемы импорта, если только проблема не повторится в pip 10. В любом случае, до тех пор, пока сопровождающие не сделают все возможное, чтобы сделать Если import pip терпят неудачу, или сразу отклоняют исправления, которые устраняют такие сбои, будет точка соприкосновения.

@sruggier Все упомянутые пакеты хороши, и WheelFile.install() также нуждается в дополнительной рекламе. Но комплексное обслуживание pip.main() незаменимо со всем вышеперечисленным. Это все еще стоит попробовать.

Самое главное, что я надеюсь, что эти потребности будут удовлетворены другим проектом, и pip10 будет доставлен без каких-либо дополнительных гарантий. Прекращение поддержки и сведение к минимуму кодовой базы — вот основные пункты основного релиза.

Конкретные детали реализации «программного обеспечения» постоянной инфраструктуры смешны. Вы не можете судить о мейнтейнерах по задокументированным случаям злоупотреблений и сдерживать колесо пипсов.

Если вы настаиваете на использовании pip в качестве библиотеки, вам придется пересмотреть множество предположений.

@drunkwcodes Просто для ясности: pip.main() проще всего заменить — вам просто нужно использовать subprocess.run([sys.executable, '-m', 'pip', <rest of args>]) .

Кроме того, причина, по которой WheelFile.install() не продвигается, заключается в том, что проект колеса также заявил, что они не предоставляют видимый пользователю API — изначально мы упомянули колесо в документах pip, но удалили его по их запросу. Тем не менее, PEP колеса довольно ясно описывает, как вы устанавливаете колесо — его несложно реализовать в стороннем модуле.

Я ценю работу, которую вы все делаете над pip, и знаю, что это непросто. Но для протокола:

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

spaCy отошел от import pip . Но некоторые люди все еще используют spaCy 1, который импортировал pip --- и по понятным причинам не прикреплял pip к выпуску патча. Если бы это изменение произошло в версии 10, наши старые версии не были бы затронуты. Мы только что выпустили исправление для решения этой проблемы.

правильная инструкция о том, как программно проверять среды python в мире pip10

Какова позиция PyPA в отношении distlib? Pip, очевидно, использует его в некотором качестве, но он также использует упаковку, которую distlib считает устаревшей.

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

Я не знаю, что distlib не рекомендует упаковку. В нем упоминается «distutils2/packaging», но distutils2 был чем-то другим.

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

Может быть, deprecates — это слишком сильное слово. Источник моего текущего понимания:

https://distlib.readthedocs.io/en/latest/overview.html#distlib -развитая-из-упаковки

А, это другая "упаковка" - именно предложенный модуль stdlib должен был заменить distutils. Он полностью отличается от проекта PyPI packaging . Возможно, стоит попросить проект distlib уточнить это различие немного лучше.

Возможно, стоит попросить проект distlib уточнить это различие немного лучше.

Это уже сделано :) См.: https://bitbucket.org/pypa/distlib/issues/100/clarify-project-positioning-and-status .

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