Pip: pip 9.0.2의 `import pip` 오류

이것도 확인할 수 있습니다. 동일한 문제를 제출하려고 합니다.

이것은 #5079의 속임수입니다 -- pip 가져오기는 지원되는 사용 사례가 아닙니다.

어서.. 단일 x.x.PATCH 버전 범프에서 엄청난 변화를 일으키고 있습니까? "main"이라고 하는 최상위 메서드의 경우? 좀 별로인 폼인거 같은데..

이것은 또한 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 릴리스에서 이 동작을 변경하려는 의도를 다운스트림으로 _announce_할 수 있습니까?

우리도 이전 버전을 사용하고 싶지 않지만 그것이 바로 우리가 한 일입니다. 9.0.2는 적어도 현재로서는 CI 환경 내에 존재하지 않습니다.

일부 OpenStack 프로젝트에서도 이 히트작을 볼 수 있습니다.

Pip 10은 약 한 달 후에 출시될 예정입니다. 내가 이해하는 한 문제는 import pip 를 사용하여 pip의 내부 기능에 액세스하는 코드에 있습니다. 우리는 공식적으로 그러한 사용을 지원한 적이 없으며 현재 한동안 지원 부족을 명시적으로 문서화했습니다(단, https://pip.pypa.io/en/latest/user_guide에서 문서의 "최신" 버전에만 있음) /#using-pip-from-your-program, 왜냐하면 해당 문서 섹션이 추가된 이후로 안정적인 새 릴리스가 없었기 때문입니다). 또한 지난 10월 내부 API 사용이 지원되지 않는다는 점을 명확히 하기 위해 내부 구조 개편을 발표했습니다(https://mail.python.org/pipermail/distutils-sig/2017-October/031642.html 참조). pip 10에 있는 해당 변경 사항은 가능한 pip 9.0.3 릴리스가 수행하는 pip에 관계없이 이러한 사용을 중단합니다. 따라서 이를 갑작스럽고 예상치 못한 파손으로 보기 어렵다.

@dstufft 가 긴급 9.0.3 릴리스를 만들고 싶다면 저는 괜찮습니다. 그러나 그것은 매우 단기적인 혜택일 뿐이며 사람들이 이미 import pip 에서 벗어나지 않았다는 점에 약간 실망했습니다. 이 문제로 피해를 입은 사람들은 여전히 ​​pip 10을 준비해야 하며 단순히 import pip._internal 로 전환하는 것은 우리가 지원하거나 권장할 일이 아님 을 이해해야 합니다.

일정 수준의 API 지원을 다시 도입하기 위한 제안은 확실히 옵션이지만(예: #5080 참조) 현재 단계에서는 그러한 변경이 pip 10으로 만들기에는 너무 늦었습니다.

이전 방식을 사용하는 사람들을 위해 코드에 의해 경고가 발생하지 않고 _로 시작하는 "내부"로 표시되지 않고 이것은 단지 버그 수정 범프이므로 실제로 이것을 갑작스럽고 예기치 않은 파손으로 보는 것이 매우 쉽다고 생각합니다. .

예, 이것은 사람들이 MAJOR 버전 업데이트에서 기대할 수 있는 변경 유형입니다. 괜찮을거야.

불행히도, 이 엄청난 변화는 PATCH 업데이트로 이루어졌습니다. 이 업데이트는 _문제를 해결하기 위한 것이지 문제를 해결하기 위한 것이 아닙니다_. 이것은 의미론적 버전 관리의 정반대입니다. 그 결과 Python 생태계 전반에 걸쳐 막대한 피해가 발생하고 있습니다.

다른 PATCH 업데이트에서 이 변경 사항을 최대한 빨리 되돌린 다음 MAJOR 버전 업데이트와 함께 주요 주요 변경 사항을 적용해야 합니다. 이미 모든 사람을 위한 모든 것을 섣부르게 깨뜨렸기 때문에 실제 주요 변경 사항이 오고 있음을 더 잘 인식할 것이라고 생각합니다.

나는 또한 이것이 안정적인 문서에 문서화되지 _않은_ 것을 고려하면 이것이 이미 문서화되고 발표되었다고 말하는 것은 경찰이라고 생각합니다. 이전의.

모든 사람에게 엄청난 골칫거리를 덜어주고 이 문제를 되돌리고 실제로 의미론적 버전 관리를 시작하십시오.

@Miserlou 알겠습니다. pip 10이 주요 버전이기 때문에 내부 이름 변경 변경을 목표로 삼았습니다. 저는 패치 릴리스용 드라이버를 잘 모릅니다. @dstufft 에서 이에 대해 핑을 보냈고, 이는 pip 10 릴리스 이전인 TLS 지원 마감일이 임박했을 때 Mac OS 사용자에게 심각한 문제를 방지하기 위한 것 같습니다. 우리는 문제가 단기 패치 릴리스를 보증할 만큼 충분히 중요할 것으로 예상했습니다. 확실히 기존 사용법을 깨려는 의도는 없었습니다.

후속 조치 9.0.3에 대한 결정은 @dstufft 에게 맡겨야 합니다. 9.0.2에 들어간 내용에 대한 세부 정보가 없거나 이 문제를 해결하는 방법을 식별하는 것이 가능한지 여부도 모릅니다. 그리고 얼마나 많은 사람들이 Mac OS 문제의 영향을 받는지 알 수 없기 때문에 9.0.2를 완전히 도입하는 것이 전반적인 이점이 될지 판단할 수 없습니다. 나는 (적어도 일부 사람들에게는) 9.0.1로 고정하는 것이 해결책이라는 것을 이해합니다. 그래서 그것이 가장 나쁜 선택이 될 수 있습니다.

macOS TLS 문제는 macOS<10.13에서 시스템 Python을 사용하는 모든 사람에게 영향을 미칩니다.

@dstufft에게 후속 조치 9.0.3의 결정을 남겨야 합니다.

@pfmoore와 같은 입장입니다.

해결 방법은 사용할 수 있는 경우 가져오기 순서를 확인하고 가져오기 pip를 다른 패키지 가져오기 위에 테스트하는 것입니다(특히, pip 가져오기 _before_ 가져오기 요청이 일부 경우를 해결하는 것으로 보입니다). (이것은 여전히 ​​공식적으로 지원되지 않는 pip의 내부 사용을 의미합니다.)

docker python 3.4가 있는 gitlab-ci의 pip 9.0.2와 동일한 문제: 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

오류는 관련이 없을 수 있지만 "서두른 릴리스" 냄새가 납니다...

@pf무어

@dstufft 가 긴급 9.0.3 릴리스를 만들고 싶다면 저는 괜찮습니다. 그러나 그것은 매우 단기적인 혜택일 뿐이며 사람들이 이미 수입 핍에서 벗어나지 않았다는 점에 약간 실망합니다. 이 문제로 피해를 입은 사람들은 여전히 ​​pip 10을 준비해야 하며 단순히 pip._internal 가져오기로 전환하는 것은 우리가 지원하거나 권장하는 것이 아니라는 점을 이해해야 합니다.

이것이 이 저장소 소유자 의 진술이라는 것이 믿기지 않습니다... 당신은 말 그대로 "f*ck 의미론적 버전 관리"와 "어쨌든 사용 중단 정책이 필요한 사람"이라고 말했습니다.

pip는 항상 소모성 python api가 없는 것으로 문서화되었습니다. 그 시점에서도 "몇 년 동안 그렇게 말한" 카르마를 되돌리려고 하는 사람들에게 실망했습니다.

@RonnyPfannschmidt 이것은 "속도 제한을 초과하여 운전할 수 없다고 100번이나 말했습니다."라고 말한 다음 모든 엔진 차량을 부싯돌 차량으로 교체하여 사람들이 제한 속도를 넘지 못하도록 속도 제한을 시행하는 것과 같습니다. 더 이상 속도 제한.

당신은 말을 돌리는 것이 너무 나쁘다는 것을 완벽하게 보여주었습니다. "그것이 깨질 것이라고 믿지 마십시오"라는 말이었습니다.

그것은 당신이 잘못하기를 싫어하기 때문에 비난을 퍼뜨리는 것입니다.

@RonnyPfannschmidt

그것은 당신이 잘못하기를 싫어하기 때문에 비난을 퍼뜨리는 것입니다.

그래서 당신은 내가 pip의 문서화되지 않은 기능에 의존하는 타사 패키지를 사용하는 것에 대해 잘못이 있다고 말하고 있습니다. 아마도, 저는... 해당 오류에 대해 해당 타사 패키지를 선별하고 문제를 제출했거나 더 나은 PR을 제출했어야 합니다.

그러나 현실을 직시합시다. 프로덕션에 사용된 많은 프로젝트가 현재 중단되어 있습니다. 이것은 도덕적인 문제가 아니라 누구의 잘못인지의 문제가 아닙니다. "이 문제를 수정하고 적절한 경고/사용 중단을 제공할 수 있습니까?"의 문제입니다.

사용하는 타사 패키지가 문서화되지 않고 보장되지 않는 내부 API에 의존하기 때문에 중단되는 경우 해당 패키지에 대해 버그를 신고해야 하는 것 같습니다.

pip 의 어떤 부분이 제3자 소비를 위한 것인지 아닌지 사이에는 쉽게 찾을 수 있는 선이 있습니다. 저는 개발자가 절대로 해서는 안 되는 내부 API를 유지하도록 강요하는 것을 지지하지 않습니다. 타사 패키지에서 사용합니다. 나는 이것을 pip 개발자의 잘못으로 취급하고 화난 사용자를 그들의 방식으로 보내는 것을 지지하지 않습니다. 누군가에게 화를 내고 싶다면 내부 API에 의존하는 패키지에 화를 내고 유지 관리자가 자신의 코드를 수정하도록 하세요.

@anx-ckreuzberger

이것이 이 저장소 소유자의 진술이라는 것이 믿기지 않습니다... 당신은 말 그대로 "f*ck 의미론적 버전 관리"와 "어쨌든 사용 중단 정책이 필요한 사람"이라고 말했습니다.

나는 여기서 좌절감을 이해하지만, 우리가 약속하지 않은 일에 대해 pip 유지 관리자를 비난하려는 사람들의 의지에 점점 짜증이 나고 있습니다.

그런 비난을 하고 싶으시다면

1. 사용자 코드에서 pip 내부 API 사용을 지원하는 pip 유지 관리자의 명령문에 대한 포인터입니다.
2. pip가 의미 체계 버전 관리를 사용하는 pip 유지 관리자의 명령문에 대한 포인터입니다.

그 증거를 찾지 못할 것 같은데...

그래서 당신은 내가 pip의 문서화되지 않은 기능에 의존하는 타사 패키지를 사용하는 것에 대해 잘못이 있다고 말하고 있습니다.

아니요, 하지만 해당 프로젝트가 아닌 pip 유지 관리자를 비난하는 것은 허용되지 않습니다. 우리는 당신을 도우려고 노력하고 있지만 그 프로젝트가 하는 일에 대해 책임을 질 수 없습니다. 그들과 함께 당신의 불만을 털어놓으십시오.

그러나 현실을 직시합시다. 프로덕션에 사용된 많은 프로젝트가 현재 중단되어 있습니다. 이것은 도덕적인 문제가 아니라 누구의 잘못인지의 문제가 아닙니다. "이 문제를 수정하고 적절한 경고/사용 중단을 제공할 수 있습니까?"의 문제입니다.

우리는 경고를 제공하려고 노력했습니다. 우리는 몇 달 전에 공지를 보내고 상황을 설명하는 문서를 추가했으며 내부 API 사용이 지원되지 않는다는 트래커의 문제에 지속적으로 답변했습니다. 비추천을 추가하는 것은 당신이 제안한 것처럼 쉽지 않습니다. pip 자체가 이러한 경고를 뿜어낼 것이기 때문입니다(또는 pip가 경고를 끄는 방법이 있고 다른 사람들은 복사할 것입니다. 우리는 이미 pip._internal import pip._internal 변경해 도 멈추지 않습니다. :disappointed:).

이 "수정"에 관해서는 긴급한 문제를 해결하기 위해 9.0.2가 신속하게 릴리스되었으며 우리는 이 문제를 예상하지 못했다는 점을 기꺼이 인정합니다. 수명이 2-3주인 9.0.3을 출시하는 것은 합리적인 일입니다. 제 생각에는 그렇게 생각하지 않습니다. 그러나 저는 우리가 그것을 고려할 것이라고 말했습니다. 나는 9.0.x 릴리스에 관련된 사람이 아니기 때문에 개인적으로 동의할 수 없습니다. 저는 pip 10에 대해 작업 중이며, 이는 이 모든 논쟁을 무의미하게 만들 것입니다. 따라서 이것이 이 문제에 대한 저의 마지막 말일 것입니다. 해당 릴리스와 관련된 사항에 집중해야 합니다.

내 개인적인 조언:

1. 이 문제의 영향을 받고 지금 해결 방법이 필요한 경우 9.0.1에 고정 하세요 .
2. pip 내부 API를 사용하기 때문에 현재 가지고 있는 모든 종속성이 끊어지면 pip 10에 대비하세요. 다시 중단됩니다. 이러한 종속성을 푸시하여 우리가 몇 달 동안 제공한 정보에 대한 조치를 취하고, 그러한 일이 발생할 것이라는 사전 경고를 받은 것을 기쁘게 생각합니다.
3. pip 9.0.3이 해제되면 핀을 제거하십시오.
4. pip 10 베타가 나오면 테스트하고 관련 당사자(내부적으로 pip를 호출하는 경우 타사 프로젝트, pip를 직접 호출하는 경우 당사)에 문제를 보고 하세요 .

도커 컨테이너 내에서 pip 9.0.2 및 Python 2.7.14에서 동일한 문제를 경험했습니다.
도커 컨테이너 외부의 개발 시스템에서 문제를 재현할 수 없습니다.
pip 가져오기( import.pip , from.pip , \'pip , \"pip 에 대한 grep'd )를 검색했지만 아무 것도 찾을 수 없습니다.
우리 Plone은 setuptools setup.py 파일에 포함된 패키지의 구성을 자동으로 포함하는 메커니즘을 사용하고 있습니다. 이는 의심스럽게 들리지만 다시 한 번 이것은 __import__ 를 사용하고 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를 사용하지 않고 가져오기만 하면 이미 중단됩니다. 이것은 파이썬 나라에서 좋은 시민 행동이 아닙니다. 사용을 지원하지 않거나 공개 API를 제공하지 않는 것은 가져오기를 중단하는 것입니다. 이것은 많은 자동 검사 코드에 영향을 미칩니다.

이렇게 생각하십시오. pip는 라이브러리가 아니라 명령줄 유틸리티입니다. Python으로 작성되었다는 사실은 관련이 없습니다. 그것이 문제의 현실입니다.

@pf무어

나는 여기서 좌절감을 이해하지만, 우리가 약속하지 않은 일에 대해 pip 유지 관리자를 비난하려는 사람들의 의지에 점점 짜증이 나고 있습니다.

이렇게 생각하십시오. pip는 라이브러리가 아니라 명령줄 유틸리티입니다. Python으로 작성되었다는 사실은 관련이 없습니다. 그것이 문제의 현실입니다.

결론은 당신이 약속한 것은 정말로 중요하지 않다는 것입니다. 중요한 것은 당신이 한 일과 결과적인 상황입니다. 아마도 당신은 그것을 명령줄 유틸리티로 생각했을 것입니다. 그러나 당신은 그것을 라이브러리로 출시했습니다. 이것이 문제의 현실입니다.

Feature X가 포함된 라이브러리를 출시했습니다. 사람들이 Feature X를 사용하기 시작했습니다. 물론 "여러분, Feature X를 사용하지 마십시오"라고 말씀하셨습니다. 그러나 당신은 그것을 Feature X로 계속 출시했습니다. 수년 동안. 그래서 사람들이 계속 사용했습니다. 크고 작은 수십, 수백, 수천 개의 프로젝트에서 지금 사용하고 있습니다. 갑자기 적절한 경고 없이 마이너 업데이트에서 제거합니다.

다음에 무슨 일이 일어날 것 같습니까?

단기적으로 사람들은 정당한 이유가 없는 한 이전 버전을 고정하고 고정을 해제하지 않을 것입니다.

장기적으로... 글쎄, 얼마나 많은 사람들이 당신이 망가진 모든 것을 수리하는 것보다 당신을 교체하는 것이 더 비용 효율적일 것이라고 결정하는지에 달려 있습니다.

@pfmoore 위에서 언급한 역추적에서 의심스러운 점이 있습니까? pip 내부 AFAIK를 사용하지 않습니다. 대부분의 사람들이 도커 컨테이너 내에서 이 문제를 갖고 있다는 것은 흥미롭습니다.

@ 모두, 깨진 코드에 대해 유지 관리자를 비난하는 것은 문제 해결에 도움이 되지 않습니다.

이렇게 생각하십시오. pip는 라이브러리가 아니라 명령줄 유틸리티입니다. Python으로 작성되었다는 사실은 관련이 없습니다. 그것이 문제의 현실입니다.

Fact: 어떤 이유에서든 코드를 자동 검사하여 가져오면 가져올 수 없습니다. 모든 중단. 나는 이것이 @t 의 경우에 발생한다고 가정합니다.
결론: pip는 패키지를 설치하는 전역 또는 현재 virtualenv/venv Python 네임스페이스에서 자체를 격리해야 합니다. 그렇게 하면 오염되지 않고 우연히 수입되는 일이 발생하지 않습니다.

먼저 잘못된 코드로 repo 관리자를 비난했다면 죄송합니다. 모든 비난은 좌절감에서 비롯되었으며, IMHO 9.0.2 릴리스 가 semver의 정의에 따라 패치 릴리스라는 사실을 지적합니다( @pfmoore 는 pip가 반드시 semver를 사용하는 것은 아님을 분명히 했습니다. 다른 날에 대한 또 다른 문제입니다).

@MikeHart85

단기적으로 사람들은 정당한 이유가 없는 한 이전 버전을 고정하고 고정을 해제하지 않을 것입니다.
장기적으로... 글쎄, 얼마나 많은 사람들이 당신이 망가진 모든 것을 수리하는 것보다 당신을 교체하는 것이 더 비용 효율적일 것이라고 결정하는지에 달려 있습니다.

꽤 많이. 내 말은 JavaScript 패키지 관리자를 살펴보는 것입니다: npm, bower, yarn, 다음 ~년~주에 출시되는 모든 것

아니요, 하지만 해당 프로젝트가 아닌 pip 유지 관리자를 비난하는 것은 허용되지 않습니다. 우리는 당신을 도우려고 노력하고 있지만 그 프로젝트가 하는 일에 대해 책임을 질 수 없습니다. 그들과 함께 당신의 불만을 털어놓으십시오.

나는 이 문제에 대한 나의 (우리의?) 불만 사항이 잘못 전달될 수 있음을 이해합니다. 이것이 제 3자 유지 보수의 잘못이라는 것을 누구에게도 납득시키는 것이 정말로 어렵다는 것을 인정해야 하지만.

우리는 경고를 제공하려고 노력했습니다. 우리는 몇 달 전에 공지를 보냈고 상황을 설명하는 문서를 추가했습니다.

이것은 pip 9.0.2용입니까 아니면 pip 10용입니까? pip 9.0.2용이라면 Changelog 에 메모가 있으면 좋을 것입니다. 어쨌든, pip 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 : "엄격"하고 싶다면 여기에서 예외를 발생시키고 유사한 명령문을 하위 모듈에 추가할 수도 있습니다.

사람들이 이 문제를 해결하기 위해 노력할 것이라는 사실은 다른 것입니다. 라이브러리를 해킹하고 싶다면 언제든지 리버스 엔지니어링할 수 있습니다. 항상 주변에서 방법을 찾을 수 있습니다. 그러나 디자인 결정에서 주변의 모든 방법을 고려해서는 안 됩니다.

장기적으로... 글쎄, 얼마나 많은 사람들이 당신이 망가진 모든 것을 수리하는 것보다 당신을 교체하는 것이 더 비용 효율적일 것이라고 결정하는지에 달려 있습니다.

저는 항상 이 "위협"이 재미있습니다. 그것은 pip와 같은 것에 투입되는 노력의 양과 실제로 비용이 얼마나 드는지(그리고 실제로 지불할 의사가 있는 사람이 얼마나 되는지)에 대한 근본적인 오해와 함께 옵니다. 당신이 더 잘할 수 있다고 느낀다면, 반드시 그렇게 하십시오. 저는 (다른 사람들도 마찬가지라고 생각합니다) 그것을 환영합니다. 지난 몇 년 동안 이러한 일이 가능하도록 하는 것이 분명한 목표 중 하나인 표준을 문서화하고 설계하는 데 적지 않은 노력이 있었습니다.

이러한 것들에 대한 관점을 유지하는 것이 중요합니다. 있습니다 .. 15 미만? 20? 사람들이 이것이 어떻게 문제를 일으켰는지에 대해 논평하는 동안(이러한 측정항목에는 항상 "빙산의 일각" 문제가 있지만) pip 9.0.2는 이미 지난 주에 두 번째로 많이 사용된 설치 프로그램입니다(존재하지도 않은 날짜까지 계산하면) for) 출시 이후 PyPI에서 1,700만 파일을 다운로드했습니다. 마지막 날만 보면 PyPI 에서 가장 많이 사용되는 설치 프로그램으로 pip 9.0.1을 추월하는 방법의 80%입니다.

따라서 이것이 일부 사람들에게 문제를 일으켰다는 것을 알고 있지만 지원되지 않는 일을 하거나 상당히 극단적인 상황에서 수행하는 사람은 상대적으로 적습니다.

시간을 찾을 수 있다면 9.0.3을 자르려고 할 수 있습니다. 주로 @thet 가 물건을 가져오려고 하는 자동 가져오기 도구일 뿐이고 실제로 사용하려고 하지 않는 경우를 해결하기 위해 어떤 식으로든 pip의 내부 API. 그것이 또한 pip의 내부 API를 사용하는 사람들의 동작을 해결하는 것으로 끝나면 구체적으로 문제를 해결하기 위해 최선을 다하지 않을 것이지만, 그렇지 않은 경우에도 문제를 해결하기 위해 노력하지 않을 것입니다. 그들 중 특히.

이 시점에서 9.0.x를 릴리스하는 데 많은 시간이 걸리며(릴리스를 수행하는 데 약간의 수정이 필요할 정도로 상황이 master 로 분기됨) 디버그에 필요한 시간은 계산되지 않습니다. 실제 문제를 수정합니다. 이런 일이 발생할 가능성을 높이려면 디버깅 및 수정을 수행하고 패치(또는 자체 포크에서 9.0.2 태그의 분기)를 제공하는 것이 가장 좋은 방법입니다.

먼저 잘못된 코드로 repo 관리자를 비난했다면 죄송합니다. 모든 비난은 좌절에서 만들어졌다

감사합니다. 여기서 좌절감이 크며 이해합니다.

그냥 하나 더 추가하면 어떨까요?

좋은 생각입니다. 우리가 이것을 좀 더 일찍 생각해 보았더라면 좋았을 텐데. 물론, 내부 네임스페이스가 pip 10에서 재구성되므로 지금은 진짜 의미가 없으므로 너무 늦었습니다. 나는 확실히 미래를 위해 이 트릭을 기억할 것입니다.

이것은 pip 9.0.2용입니까 아니면 pip 10용입니까?

10.0의 경우. 9.0.2를 릴리스하려는 원래 의도는 없었고, TLS 변경 사항이 적용될 때 Mac OS 사용자가 PyPI에 대한 모든 액세스 권한을 잃지 않도록 긴급 릴리스로만 수행했습니다.

@dstufft 가 여기에서 훨씬 더 완벽하게 응답했으므로 이것이 현재로서는 가능한 한 해결되었다고 생각합니다.

저는 항상 이 "위협"이 재미있습니다.

전혀 위협적이지 않습니다. 그런 식으로 들렸다면 죄송합니다.

소프트웨어 세계에서 너무나 자주 일어나는 일에 대한 관찰입니다. 사람들은 당신의 약속이나 의도에 따라 일하지 않습니다. 사람들은 당신이 제공하는 제품으로 일합니다. 귀하의 제품에 많은 사람들이 의존하게 되는 기능이 있다면 더 이상 발 아래에서 빼낼 수 없습니다. 그렇게 하면 제품이 파손된 것으로 보기 시작합니다. 당신이 제공하는 유일한 설명이 "음, 우리는 어쨌든 이것을 약속한 적이 없습니다"라면 그들은 당신이 그들의 우려를 책임으로 인정하지 않으려는 것을 보기 시작합니다.

그럴수록 대안에 대한 욕구와 요구가 커집니다. 물론 사람들은 그 작업이 얼마나 필요한지 과소평가합니다. 그러나 그것은 그들이 하나의 작업을 시작할 가능성을 더 많이, 더 적게 만들 뿐입니다. 그 공은 일단 굴러가고 나면 그 자체의 생명을 갖게 됩니다.

대안이 항상 좋은 것은 아닙니다. 그들은 일을 엉망으로 만드는 경향이 있습니다. 개인적으로 단일 패키지 관리자를 선호합니다. 모두를위한. 그러나 저는 Python용 단일 패키지 관리자로 정착할 것입니다.

사람들이 의도한 것이든 아니든 간에 기능을 중단했다고 보고하면 "이 기능이 계속 지원되지 않았습니다"라는 우려를 무시하기보다 중단해야 하는 이유 또는 유지하지 못하는 이유 를 간략하게 설명하는 것을 고려하십시오.

@dstufft님 , 참여해주셔서 감사합니다. 이 스레드는 점점 더 뜨거워지고 있습니다!

먼저 노고에 감사드립니다! 유지 관리가 끝이 없고 감사할 수 없는 작업이라는 것을 알고 있으며 pip 만큼 크고 인기 있는 프로젝트를 관리할 때만 더 악화될 것이라고 상상합니다!

이제 당면한 문제로: 지금까지 20명의 _maintainers_가 이 문제를 보고했지만 이미 수천 명의 _명에게 영향을 미치고 있다는 것을 알고 있습니다. 영향을 받는 일부 프로젝트는 그 자체로 막대한 규모입니다. Anaconda, OpenStack, SpaCy, Zappa 및 수만 명의 사용자. Slack 채널이 이에 대한 토론으로 넘쳐난다는 것을 알고 있습니다. (말 그대로 이 글을 쓰면서 새로운 이슈가 생겼습니다.)

분명히, 프로그래밍 방식으로 환경을 검사하는 기능이 필요한 중요한 Python 프로젝트가 많이 있습니다. 이것은 할 수 있어야 하는 완전히 합리적인 일입니다. 게다가 문서에서는 이렇게 하는 것에 대해 경고한 적이 없으며 여전히 경고하지 않습니다! (이 리포지토리의 README에서 문서 링크를 클릭하세요!)

지금까지의 상황은 다음과 같다고 생각합니다.

• 버전 문자열의 형식이 주어지면 우리 모두는 pip 유지 관리자가 의미론적 버전 관리를 따르고 있다고 믿었습니다.
• pip 유지 관리자는 대대적인 변경을 도입한 "패치"를 출시했습니다.
• 이 변경 사항은 예고되지 않았고 문서화되지 않았습니다. 그리고 제 생각에는 예상치 못한 의도하지 않은 것으로 가정합니다.
• 이제 import pip 를 호출하는 것만으로도 프로그램이 즉시 중단되며 이는 매우 개발자에게 적대적입니다.
• 이것은 파이썬 생태계 전반에 걸쳐 큰 골칫거리를 일으키고 있습니다.
• 문서는 pip 를 프로그래밍 방식으로 사용하는 것에 대해 경고하지 않습니다(그리고 _여전히_ - 이 리포지토리의 README에 있는 문서 링크를 클릭하지 않음).
• import pip 가 PATCH 업데이트에서 이 피해를 일으킬 것이라는 발표는 없었습니다. 그 발표는 _아직 출시되지 않은_ 버전에 대한 것입니다.
• 이 변경 사항은 변경 로그에도 언급되지 않았습니다.
• 우리는 pip나 pip 개발자를 교체하고 싶지 않습니다! 우리는 너를 사랑해!
• ..하지만 우리는 이러한 유형의 일이 다시는 발생하지 않기를 바랍니다!
• ..그래서 우리는 semver가 팔로우되기를 원합니다!
• 우리는 이 주요 변경 사항을 취소하는 또 다른 PATCH 를 정말 정말 원합니다!

pip>=10.0.0 세계에서 환경을 검사하는 프로그래밍 방식의 필요성은 다른 토론의 주제이지만 당면한 문제는 pip에서 프로그래밍 방식으로 pip를 사용해서는 안된다는 말을 들어본 적이 없다는 것입니다. <=9 세계, 그리고 대규모의 예고 없는 변화가 있었고 수천 명의 사람들에게 부정적인 영향을 미치기 때문에 우리는 그것이 역전되기를 정말로 원합니다.

다시 한 번 감사합니다.
부자

우선, 프로젝트 내에서 그들의 노력과 통찰력에 대해 pip 관리자에게 감사드립니다. 나는 이것이 다른 사람들이 문제를 이해하는 데 정말로 도움이 된다고 생각합니다(하지만 그것에 대한 요약 블로그 기사를 작성할 가치가 있을 수 있음).

@dstufft

이러한 것들에 대한 관점을 유지하는 것이 중요합니다. 있습니다 .. 15 미만? 20? 사람들이 이것이 어떻게 문제를 일으켰는지에 대해 논평하는 동안(이러한 측정항목에는 항상 "빙산의 일각" 문제가 있지만) pip 9.0.2는 이미 지난 주에 두 번째로 많이 사용된 설치 프로그램입니다(존재하지도 않은 날짜까지 계산하면) for) 출시 이후 PyPI에서 1,700만 파일을 다운로드했습니다. 마지막 날만 보면 PyPI에서 가장 많이 사용되는 설치 프로그램으로 pip 9.0.1을 추월하는 방법의 80%입니다.

나는 메트릭이 지속적 통합/전달 시스템의 모든 자동화된 pip install pip --upgrade 명령에 의해 크게 편향되어 있다고 확신합니다(캐시를 사용해야 하므로 항상 pypi에서 패키지를 다시 설치할 필요가 없습니다. 동시에 import pip 도 해서는 안 됩니다. 이것이 IT 세계가 작동하는 방식입니다.

15명 미만의 사람들이 이에 대해 불만을 제기했다는 사실이 다음 두 가지를 알려줍니다.

1. 많은 사람들이 아직 프로덕션에서 9.0.2를 사용하고 있다고 생각하지 않습니다. 일부는 여전히 이 문제를 디버그하려고 할 수 있으며 해결될 때까지(또는 영원히 .. .) - 또한 어떤 사람들은 아직 작동하지 않는 것이 있다는 것을 눈치채지 못했을 수도 있습니다...
2. 출시 2일 만에 벌써 이야기를 하는 사람들이 있다. 더 많은 사람들이 이 문제를 겪을 것입니다. 2주 동안 기다리면 100명의 사람들이 그것에 대해 불평하게 될 수 있습니다(예: 스프린트를 마치고 QA/스테이징에 배포할 때). 이 시점에서 얼마나 많은 사람들이 이 변경으로 인해 영향을 받을지 모릅니다.

어쨌든, 이 문제에 대해 이야기하고 논쟁하는 것은 사람들이 내부 API에 절대 의존해서는 안 되는 이유에 대한 좋은 예를 제공하며, 희망적으로 일부 타사 패키지 유지 관리자는 여기에서 논의된 내용으로 인해 프로젝트를 업데이트할 것입니다.

분명히, 프로그래밍 방식으로 환경을 검사하는 기능이 필요한 중요한 Python 프로젝트가 많이 있습니다. 이것은 할 수 있어야 하는 완전히 합리적인 일입니다. 게다가 문서에서는 이렇게 하는 것에 대해 경고한 적이 없으며 여전히 경고하지 않습니다! (이 리포지토리의 README에서 문서 링크를 클릭하세요!)

왜 이것을 경고해야 하는지 나에게는 명확하지 않습니다. pip 를 명령줄 도구 이외의 다른 용도로 사용하는 것은 완전히 문서화되지 않았습니다. 문서를 검색하면 pip 가져오기에 대한 참조가 전혀 표시되지 않습니다. Chrome에서 사용하는 일부 .so 에 대해 링크하고 ABI 호환성을 깨뜨렸기 때문에 불평하는 것과 같습니다.

SemVer의 일반적인 해석은 문서화되지 않은 내부가 아니라 지원되는 공용 인터페이스(이 경우 CLI)에 적용된다는 것입니다. 내부를 사용하는 사람은 어쨌든 pip 버전을 고정해야 합니다. 왜냐하면 그것들은 임의적으로 변경될 수 있기 때문입니다.

정말 반전이 없습니다. macOS 사용자의 상당수가 가까운 장래에 PyPI에 액세스할 수 없도록 하는 수정 사항을 백포팅하면 지원되지 않는 조건에서만 자체적으로 표현되는 것으로 보이는 9.0.x 코드 기반에 적용될 때 버그가 있습니다. 앞으로 나아갈 유일한 길은 9.0.x 시리즈에서 해당 버그를 해결하기 위해 추가 작업을 수행하는 것입니다. 내가 말했듯이 시간을 낼 수 있으면 해보고 싶고, 그런 일이 일어날 확률을 높이려면 패치를 제공하세요.

문서에서는 pip로 수행할 수 있지만 지원되지 않는 작업의 전체 목록을 제공할 수 없기 때문에 이에 대해 경고하지 않습니다. 대신 우리는 지원되는 것을 문서화하는 상당히 일반적인 접근 방식에 의존하고 문서화되지 않은 모든 것은 지원되지 않는 것으로 가정해야 합니다(그리고 문서화되지 않은 것에 의존하려는 경우 문서화 및 지원을 요청하는 문제를 엽니다. ).

장기적으로 우리는 우리가 semver인지 아닌지에 대한 혼란을 제거하기 위해 날짜 기반 릴리스 계획으로 이동할 가능성이 있습니다.

내 iPhone에서 보낸

2018년 3월 20일 오전 11:02에 Rich Jones [email protected] 이 다음과 같이 썼습니다.

@dstufft님 , 참여해주셔서 감사합니다. 이 스레드는 점점 더 뜨거워지고 있습니다!

먼저 노고에 감사드립니다! 유지 관리가 끝이 없고 감사할 수 없는 작업이라는 것을 알고 있으며 pip만큼 크고 인기 있는 프로젝트를 관리할 때만 문제가 더 악화될 것이라고 상상합니다!

이제 당면한 문제에 대해: 지금까지 20명의 유지 관리자가 이 문제를 보고했지만 이미 수천 명의 사람들에게 영향을 미치고 있다는 것을 알고 있습니다. 영향을 받는 일부 프로젝트는 그 자체로 막대한 규모입니다. Anaconda, OpenStack, SpaCy, Zappa 및 수만 명의 사용자. Slack 채널이 이에 대한 토론으로 넘쳐난다는 것을 알고 있습니다. (말 그대로 이 글을 쓰면서 새로운 이슈가 생겼습니다.)

분명히, 프로그래밍 방식으로 환경을 검사하는 기능이 필요한 중요한 Python 프로젝트가 많이 있습니다. 이것은 할 수 있어야 하는 완전히 합리적인 일입니다. 게다가 문서에서는 이렇게 하는 것에 대해 경고한 적이 없으며 여전히 경고하지 않습니다!

지금까지의 상황은 다음과 같다고 생각합니다.

버전 문자열의 형식이 주어지면 우리 모두는 pip 유지 관리자가 의미론적 버전 관리를 따르고 있다고 믿었습니다.
pip 유지 관리자는 대대적인 변경을 도입한 "패치"를 출시했습니다.
이 변경 사항은 예고되지 않았고 문서화되지 않았습니다. 그리고 제 생각에는 예상치 못한 의도하지 않은 것으로 가정합니다.
이제 import pip를 호출하는 것만으로도 매우 개발자에게 적대적인 프로그램이 즉시 중단됩니다.
이것은 파이썬 생태계 전반에 걸쳐 큰 골칫거리를 일으키고 있습니다.
문서는 프로그래밍 방식으로 pip를 사용하는 것에 대해 경고하지 않습니다.
패치 업데이트에서 pip 가져오기가 이 손상을 일으킬 것이라는 발표는 없었습니다. 해당 발표는 아직 출시되지 않은 버전에 대한 것입니다.
이 변경 사항은 변경 로그에도 언급되지 않았습니다.
우리는 pip나 pip 개발자를 교체하고 싶지 않습니다! 우리는 너를 사랑해!
..하지만 우리는 이러한 유형의 일이 다시는 발생하지 않기를 바랍니다!
..그래서 우리는 semver가 팔로우되기를 원합니다!
우리는 이 주요 변경 사항을 취소하는 또 다른 PATCH를 정말 정말 원합니다!
pip>=10.0.0 세계에서 환경을 검사하는 프로그래밍 방식의 필요성은 다른 토론의 주제이지만 당면한 문제는 pip에서 프로그래밍 방식으로 pip를 사용해서는 안된다는 말을 들어본 적이 없다는 것입니다. <=9 세계, 그리고 대규모의 예고 없는 변화가 있었고 수천 명의 사람들에게 부정적인 영향을 미치기 때문에 우리는 그것이 역전되기를 정말로 원합니다.

다시 한 번 감사합니다.
부자

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

@Miserlou

버전 문자열의 형식이 주어지면 우리 모두는 pip 유지 관리자가 의미론적 버전 관리를 따르고 있다고 믿었습니다.

semver에 강력하게 반대하는 사람으로서 이 혼란을 없애기 위해 내 버전 문자열이 어떤 형식이어야 하는지 알려주실 수 있습니까? "점 3개"가 나에게 "엄격히 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의 패키지 관리자입니다. 파이썬은 프로그래밍 언어입니다. 사람들은 프로그래밍 방식으로 환경을 검사해야 합니다. 1+1=2.

사람들이 이것이 올바른 방법이라고 가정하는 것은 완전히 합리적이었습니다. 문서에는 이 작업을 _하지 _ 하지 않는다는 내용이 - 그리고 _ 여전히 _ 없습니다. 동일한 결론에 도달한 700,000개 이상의 응용 프로그램이 있음을 상기시켜 드립니다! 또한 - 다른 방법은 없습니다!

ReadTheDocs에 문서화되지 않은 것이 있다고 해서 그것이 금지된 것은 아닙니다. 우리 모두는 단순히 이런 방식으로 코드를 제공하는 프로젝트를 매일 접하고 사용합니다.

어쨌든 pip 조차도 명령줄 인터페이스를 _가지고_ 있다는 사실은 이미 Python 클라이언트가 있기 때문에 라이브러리로 사용할 수 있다는 좋은 표시인 것 같습니다!

게다가, 우리는 관례와 같이 _ 로 네임스페이스가 지정된 비공개 API에 대해 이야기하고 있지 않으며, 심지어 특정 공개 메서드에 대해서도 이야기하는 것이 아니라 이 치명적인 실패를 일으키는 _import를 호출하는 것_에 대해서만 이야기하고 있습니다.

문서에 이렇게 하지 말라는 내용은 없었고 지금도 없습니다.

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

_이 바로 저장소_의 "문서" 링크를 클릭하면 해당 페이지로 이동할 수 없습니다. 아무도 최신을 참조하지 않습니다. 문서에 대한 자체 링크는 최신 링크로 연결되지 않습니다. 해당 페이지로 이동할 수 있는 방법이 없습니다. 해당 섹션을 포함하지 않는 모든 것이 안정적으로 이동합니다.

@Miserlou 나는 그 메모가 파이썬에서 구현되고 해당 내부를 가져올 수 있기 때문에 명령줄 도구의 내부를 가져와야 한다고 어떻게든 생각하는 사람들을 위한 친절이라고 생각합니다.

pip 의 공용 인터페이스에 대한 해석이 나와 개발자 및 pip 를 CLI 프로그램으로 생각하는 대부분의 사람들과 다르다는 것을 알았습니다. 그러나 이것의 실제 피해는 무엇입니까? pip != 9.0.2 를 고정하고 끝냅니다.

지원되는 공개 API의 일부가 무엇이고 일부가 아닌지에 대해 이 시점에서 우리는 모두 같은 페이지에 있다는 것이 분명하며, 모든 사람에게 소급하여 통지하기 위해 지금 할 수 있는 일은 없습니다.

솔직히 말해서, pip의 유지 관리자는 이미 시간이 허락한다면 이 문제를 해결하려고 노력할 것이라고 밝혔지만 모든 사람이 속도를 높이기 위해 풀 요청을 제출하는 것이 좋습니다.

현재로서는 타사 라이브러리가 이 문제를 인식하고 이 문제를 지적하도록 하는 것이 우리가 할 수 있는 전부라고 생각합니다. 장기 타사 라이브러리는 어쨌든 이 문제를 해결해야 하며 import pip 하지 않고 명령줄을 통해 pip를 호출하는 방식으로 해결해야 합니다(하위 프로세스 또는 유사한 python 명령 사용).

나는 이 토론이 생산적이지 않을 것이라고 생각하며 실제로 더 말할 것도 없습니다. 있습니다:

• 문제에 대한 적절한 설명.
• 누군가가 문제에 직면했을 때 사용할 수 있는 가능한 해결 방법.
• 이전 버전과의 호환성 지침에 따라 이를 주요 변경 사항으로 간주하지 않는 이유.
• 그것을 고칠 시간을 찾으려고 노력할 것이라는 진술(약속은 없지만).
• 이 문제의 영향을 받는 누군가가 수정 사항과 함께 9.0.3 가 존재할 가능성을 높이고자 하는 경우 수행할 수 있는 행동 촉구입니다.

이 시점에서 토론은 관련된 모든 사람들을 더 좌절시키는 것 외에는 실질적인 목적이 없으므로 지금은 이 문제에서 물러납니다. 이 문제는 10.0 또는 9.0.3이 출시되면 종료됩니다. 누군가가 Call To Action에 노력을 기울이면 풀 리퀘스트를 열거나 이 문제에 대한 diff를 제출할 수 있습니다.

이 do-not-import-pip 만트라를 더 잘 보이게 하려면 네임스페이스의 이름을 "_pip"로 바꾸는 것은 어떻습니까? 이것은 전체가 이름 수준에서 공개적으로 사용되지 않음을 나타냅니다.
또한 자동 검사 코드에 밑줄로 시작하는 항목을 보지 않도록 지시하는 것이 더 쉬울 것입니다. 글쎄요, 후자는 관련 검사 코드도 변경해야 합니다. 그러나 적어도 블랙리스트를 관리하지 않고 (관례에 따라) 자동화할 수 있는 기회가 있습니다.

자, 마지막으로 맹세합니다. pip 10은 이미 모든 관련 코드를 pip._internal python -m pip _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의 영향을 받습니다.

I 두 번째/세 번째/N 번째 적절한 사용 중단 경고가 더 원활하게 추가됩니다. 어쩌면 pypi.python.org 게시물도 될까요?

만세! 감사합니다!

또한 사용 중단 경고와 더 중요한 것은 pip10 세계에서 파이썬 환경을 프로그래밍 방식으로 검사하는 방법에 대한 적절한 지침을 정말 좋아합니다! 700,000개 이상의 응용 프로그램 이 이 버그의 영향을 받았다는 점을 감안할 때 분명히 그럴 필요가 있습니다.

pip list --format=json ?

먼저 pip 사람들에게 몇 가지 사용자 친화적인 옵션과 인수를 포함하여 제 모든 사용 사례를 완전히 다룹니다.

이 "놀랍도록 널리 채택되고 유용한 정의되지 않은 동작" 으로 인해 piplib를 git용 libgit2로 만들어야 합니까? libgit2는 git과 코드를 공유하지 않으며 git의 다른 그룹에서 유지 관리합니다. 그리고 git 생태계에 좋습니다. 아마도 piplib는 우리가 예상하지 못한 몇 가지 흥미로운 사용 사례를 다룰 것입니다.

비슷한 이야기가 있습니다. https://public-inbox.org/git/1267957655.3759.29.camel@mattotaupa/T/

@drunkwcodes 나는 당신이 제안한 것이 pip 문서 에서 언급 한 기존 패키지 packaging , setuptools 및 distlib 에 이미 구현되어 있다고 생각합니다. 이 스레드에서 알 수 있는 한 기능의 격차에는 문제가 없지만 일부 사람들은 모든 모듈을 가져오고 검사하려고 하고 가져오기 실패를 치명적인 오류로 처리하는 도구에 문제가 있습니다.

그런 도구는 try/except 블록에 import 문을 래핑하여 이 문제를 해결할 수 있는 것 같지만, 이것도 설정해야 할 의심스러운 선례처럼 보입니다. 그러나 pip 9.0.3의 릴리스를 감안할 때 pip 10에서 문제가 다시 발생하지 않는 한 가져오기 문제에 대해 토론할 시간이 없을 것이라고 생각합니다. 어쨌든 유지 관리자가 import pip 실패하거나 그러한 실패를 수정하는 패치를 간단히 거부하는 경우에는 공통된 근거가 있습니다.

@sruggier 언급 된 패키지는 모두 훌륭하고 WheelFile.install() 도 더 많은 홍보가 필요합니다. 그러나 제공되는 원스톱 서비스 pip.main() 는 위의 모든 것과 대체할 수 없습니다. 여전히 시도해 볼 가치가 있습니다.

가장 중요한 것은 이러한 요구 사항을 다른 프로젝트에서 유지하고 pip10이 추가 보증 없이 원활하게 도착하기를 바랍니다. 사용 중단 및 코드 기반 최소화는 주요 릴리스의 요점입니다.

영구 인프라 "소프트웨어"에 대한 구체적인 구현 세부 정보는 우스꽝스럽습니다. 문서화된 남용 사례로 유지 관리자를 판단하고 핍의 바퀴를 억제할 수 없습니다.

pip를 lib로 사용하기를 주장한다면 많은 가정을 재고해야 합니다.

@drunkwcodes 명확히 하자면 , pip.main() 는 교체하기 가장 쉬운 사용법입니다. subprocess.run([sys.executable, '-m', 'pip', <rest of args>]) 사용하면 됩니다.

또한 WheelFile.install() 가 승격되지 않는 이유는 wheel 프로젝트에서도 사용자가 볼 수 있는 API를 제공하지 않는다고 명시했기 때문입니다. 우리는 원래 pip 문서에서 wheel을 언급했지만 요청에 따라 제거했습니다. 휠 PEP는 휠을 설치하는 방법에 대해 매우 명확합니다. 타사 모듈에서 구현하는 것은 어렵지 않습니다.

여러분 모두가 pip에서 하는 일에 감사하며 그것이 쉽지 않다는 것을 알고 있습니다. 그러나 기록을 위해:

나는 사람들이 이미 import pip에서 멀어지지 않았다는 사실에 약간 실망했습니다. 이 문제로 피해를 입은 사람들은 여전히 ​​핍 10을 준비해야 합니다.

spaCy 가 import pip 에서 멀어졌습니다. 그러나 일부 사람들은 여전히 ​​pip를 가져온 spaCy 1을 사용하고 있습니다. --- 명백한 이유로 pip를 패치 릴리스로 고정하지 않았습니다. v10에서 변경 사항이 적용되었다면 이전 버전은 영향을 받지 않았을 것입니다. 이 문제를 해결하기 위해 핫픽스를 출시했습니다.

pip10 세계에서 파이썬 환경을 프로그래밍 방식으로 검사하는 방법에 대한 적절한 지침

distlib에 대한 PyPA의 입장은 무엇입니까? Pip은 분명히 그것을 어느 정도 사용하고 있지만 distlib가 더 이상 사용하지 않는 패키징을 사용하는 것도 마찬가지입니다.

공식적인 입장이 없다면, 최소한 pip의 핵심 메인테이너들의 현재 생각과 의견은 대단히 감사할 것입니다. 다른 곳에서 이 주제에 대한 관련 토론이 있는 경우 다른 토론에 대한 간단한 포인터만으로도 충분합니다.

distlib가 패키징을 더 이상 사용하지 않는다는 것을 알지 못합니다. "distutils2/packaging"을 언급하지만 distutils2는 뭔가 다릅니다.

내 개인적인 견해는 distlib와 포장 모두 사용하기에 완벽하게 합리적인 것입니다. 당신이 의존하는 다른 의존성과 마찬가지로, 분명히 당신의 요구 사항을 충족하는지 확인하기 위해 직접 평가해야 합니다.

아마도 deprecates는 단어가 너무 강합니다. 현재 이해의 출처:

https://distlib.readthedocs.io/en/latest/overview.html#distlib -evolved-out-of-packaging

아, 그것은 다른 "패키징"입니다. distutils를 대체하기 위해 제안된 stdlib 모듈이었습니다. PyPI packaging 프로젝트와 완전히 다릅니다. distlib 프로젝트에 그 차이를 좀 더 명확히 해달라고 요청할 가치가 있습니다.

distlib 프로젝트에 그 차이를 좀 더 명확히 해달라고 요청할 가치가 있습니다.

이미 완료했습니다 :) 참조: https://bitbucket.org/pypa/distlib/issues/100/clarify-project-positioning-and-status

이 스레드는 닫힌 후 최근 활동이 없었기 때문에 자동으로 잠겼습니다. 관련 버그에 대한 새 문제를 여십시오.