역사에 대해서는 #4805 및 #3389를 참조하십시오. 기본적으로 pip는 "순수한" distutils에 의해 설치된 패키지를 제대로 제거할 수 없습니다. distutils가 그렇게 하기에 충분한 메타데이터를 기록하지 않기 때문입니다. 이전에 설치 메타데이터를 제거하여 설치한 것처럼 보이지만 파일을 남겨두어야 했습니다. 문제가 발생합니다. pip 8 이후로 문제의 원인이 되었기 때문에 이 작업을 중단하려고 했지만 당시 너무 많은 사람들에게 영향을 미쳤기 때문에 초기 시도가 취소되었습니다. pip 10을 사용하여 distutils 패키지를 제거하려는 시도를 마침내 중단했으며 이제 여기에서 볼 수 있는 것처럼 사용자에게 문제를 보고합니다.

기본적으로 distutils를 사용하여 패키지를 설치한 경우(또는 사용하는 일부 인프라) "distutils를 사용하여" 패키지를 관리(특히) 제거해야 합니다. 불행히도 distutils에는 제거 명령이 포함되어 있지 않으므로 "distutils를 사용하여 제거"는 패키지를 수동으로 제거하는 것을 의미합니다.

@pfmoore 빠른 답변 감사합니다!

이것은 대부분의 패키지가 종속성으로 설치되고 우리가 직접 관리하지 않기 때문에 다소 불편합니다. 제거를 자동화하는 것은 흥미로울 것입니다.

패키지를 먼저 제거하지 않고 업그레이드만 하려는 움직임이 있습니다. 이것이 결국 일어난다면 좋을 것입니다.

이 문제는 다른 곳에서 널리 논의되기 때문에 종료할 수 있습니다. 감사 해요!

"site-packages"에서 수동으로 패키지를 제거해 보십시오. 이것은 완벽하게 작동합니다!

명령과 함께 pip 버전을 제공하여 이 문제를 해결하는 것 같습니다.
핍 설치 -I==9.0.3 -r 요구 사항.txt

다음 단계를 사용하여 이 문제를 해결했습니다.

1. 축소 버전:
   pip install --upgrade --force-reinstall pip==9.0.3
2. 패키지 재설치 시도:
   pip install xxx --disable-pip-version-check
3. 마지막으로 pip의 최신 버전을 복구합니다.
   pip install --upgrade pip

이것은 나를 위해 문제를 해결하는 것 같습니다 : https://github.com/blockstack/blockstack-core/issues/504

위의 원래 경우에는 다음과 같습니다.

pip install docker-py --ignore-installed PyYAML

당신이 누구인지 모르지만 나는 당신을 사랑합니다.

@pfmoore pip 설치를 자동화하는 팀에 무엇을 추천하시겠습니까? terraform을 사용하여 서버를 설정했으므로 smart-open 및 boto3에 대해 자동으로 pip install을 호출한 다음 requirements.txt에 numpy, scipy, boto, sklearn 및 datadog이 있습니다. 다중 설치의 경우 urllib3에 대해 distutils 오류가 발생합니다(스마트 열기가 설치했기 때문에). --ignore-installed urllib3 사용할 때 설치가 작동하지만 이에 대해 더 적절한 방법이 있습니까?

또한 distutils가 제거 기능이나 더 많은 메타데이터를 추가할 가능성이 있습니까? 이에 대해 해당 팀과 이야기를 나눈 적이 있습니까?

@ruby-is-pretty-cool 나는 그것에 대해 진짜 의견이 없습니다. 당신은 urllib3에 대해 "스마트 오픈이 설치했기 때문에"라고 말했지만 urllib3에 대한 종속성을 선언하는 smart-open에는 아무 것도 표시되지 않으므로 그것이 무엇을 의미하는지 모르겠습니다. smart-open이 이 문제를 유발하는 방식으로 urllib3를 설치하는 경우 smart-open 문제처럼 들립니다.

또한 distutils가 제거 기능이나 더 많은 메타데이터를 추가할 가능성이 있습니까? 이에 대해 해당 팀과 이야기를 나눈 적이 있습니까?

내가 아는 것은 아니며, 우리는 그것에 대해 이야기하지 않았습니다. distutils가 요즘 새로운 기능을 실제로 구현하지 않기 때문에 그렇게 할 것인지 의심스럽습니다(그러나 원하는 경우 자유롭게 물어보세요). 공식 패키징 문서는 어쨌든 distutils를 직접 사용하는 것을 권장하지 않으므로 프로젝트가 그렇게 하는 경우 영향을 관리하는 것은 실제로 그들에게 달려 있습니다.

스마트오픈을 설치해 보았습니다. 그것은 차례로 urllib3에 의존하는 요청에 의존합니다. virtualenv에 설치할 때 pip에 의해 제대로 설치됩니다. 시스템 환경에서 이 설치를 수행하고 있습니까? 어떤 경우에 urllib3가 설치된 시스템을 보고(그리고 업그레이드를 시도하고 있습니까)? 그렇다면 "시스템 패키지에 pip를 사용하지 마십시오"라는 일반적인 조언이 적용됩니다. virtualenv를 사용하거나 시스템 환경에 설치해야 하는 경우 배포 패키지를 사용하십시오.

저는 Python 패키징을 처음 접했지만 virtualenv 또는 distro 패키지가 우리 문제를 해결할 것이라고 생각합니다. 더 살펴봐야 합니다. 도와주셔서 감사합니다!

이건 미친 짓이야. 일부 종교 같은 믿음 때문에 설치가 깨지고 있습니다. 일부 패키지의 일부 setup.py 항목이 urllib3에 닿으면 이를 무시하도록 지시할 방법이 없습니다. 우리의 경우 Ubuntu 14에서 설치된 pip(v1.5.x) 버전이 https URL에서 패키지 설치를 거부하기 때문에 urllib3를 업그레이드해야 합니다.

요점은 "시스템" 패키지가 작동을 멈추지 않는다면 아무도 업그레이드하지 않을 것이라는 점입니다. Linux 커널 프로젝트에서 이 동작은 "사용자 공간을 깨뜨리는" 것이며 Torvalds는 이에 잘 반응하지 않습니다. 파이썬 사람들이 그것을 자연스럽게 잘 받아들이는 것은 놀라운 일입니다.

최소한 pip 메시지에서 "이 버전의 pip는 시스템 패키지 업그레이드를 의미하는 경우 작동을 거부할 것입니다. 이 작업을 수행하고 수행하십시오. 이전 설치 프로그램 또는 이전 설치 프로그램으로 작업하는 경우 pip 버전 9.x를 사용하십시오. 시스템." 또는 유사.

좋아, 나는 내 것이 여전히 호스에 묶여 있기 때문에주의를 기울이지 않았지만 내 요점은 더 간단합니다.
사용자 영역을 공격적으로 업그레이드하는 전체 이유는 다음과 같습니다. ATT&T와 버클리는 여전히 누가 쓰레기통을 만들었는지에 대해 얕잡아보고 있었습니다... 그리고 만약 당신이 aha1542에 설치해야 할 똥이 있다면, 라이선스로 인해 투여된 joilet를 버릴 수 있습니다. 그리고 그것이 최근에 나왔기 때문에 그들은 우리가 처음에 이 짓을 하는 이유를 추론합니다. 그리스도를 위해 선택하고 협력하는 것입니다. 나는 여전히 slackeware와 *bsd 경로가 왜 딥엔드에 들어갔는지 어리둥절하지만 어쨌든, 두 진영에서도 1이 다른 진영을 구동하고 커널이 지루해 2.x, 16+ 화면으로 돌아가서, (나는 아직 메뉴에서 promix 드라이버를 찾지 못했지만, 나는 빠져 나와 이제 정규 일정으로 돌아가서 WTF는 .app을 얻을 수 없으므로이 똥이 작동합니다. (물론 망쳐.)

@pabloa에 동의합니다 - 이것은 지금 영원히 계속되고 있습니다. 이로 인해 CentOS 7의 기본 설치는 docker-compose 설치할 수 없습니다.

그리고 예, @JohnBDonner , 그 작은 깃발이 저에게 많은 시간을 절약해 주었습니다. 감사 해요

초기 오류

"'pywin32'를 제거할 수 없습니다. distutils가 설치된 프로젝트이므로 어떤 파일이 해당 프로젝트에 속하는지 정확히 확인할 수 없으므로 부분 제거만 가능합니다."

내가 거기 어떻게?

내 컴퓨터에 pywin32==221이 설치되어 있고 이제 업그레이드 버전(pywin==224)을 제거하려고 합니다. ".whl"에 대한 링크를 얻었고 이를 설치하는 데 어려움을 겪고 있습니다. "'pywin32'를 제거할 수 없습니다. distutils가 설치된 프로젝트이므로 어떤 파일이 어떤 파일에 속하는지 정확하게 확인할 수 없으므로 부분 제거만 가능합니다."." . 저는 py3.4 32비트를 사용하는 Window 10 64비트를 사용하고 있습니다.

내가 이 일을 하는 이유는?

내 컴퓨터의 "win32.client"에는 "최적화" python 파일 ".pyo 파일 확장명"만 있는 것처럼 보이기 때문입니다. 나는 "from win32com.client import Dispatch"에 사용할 수 있는 "Dispatch" 모듈이 없다는 컴파일 오류를 받았을 때 이것을 발견했습니다. 누구든지 이것에 대해 나를 도울 수 있다면 감사합니다.

형 미쳤어??

아니요, 하지만 무작위로 악용해 주셔서 감사합니다. 여가 시간에 이 일을 하는 것이 매우 보람 있는 일입니다. :스마일:

문제를 해결하기 위한 것이 아니었습니다. 상황이 왜 그대로인지, 왜 pip가 문제를 해결할 수 없는지 설명하기 위한 것입니다. 사람들이 상황에 대해 슬퍼한다고 해서 상황이 바뀌지는 않습니다.

disyutils에서 사용하는 설치 프로그램 패키지를 다음과 같이 변경할 수 있습니까?
필요한 메타 데이터가 포함되어 있습니까?
2018년 11월 22일 목요일 오후 12:56 Paul Moore [email protected]
썼다:

문제를 해결하기 위한 것이 아니었습니다. 이유를 설명하기 위함이었다.
상황은 그대로이며 pip가 문제를 해결할 수 없는 이유입니다. 단지
사람들이 상황에 대해 슬퍼한다고 해서 상황이 바뀌지 않기 때문입니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/pypa/pip/issues/5247#issuecomment-441095536 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ADrjCZvIpDr4X1sxcSZe3rRH7MBnn7Tsks5uxuVagaJpZM4TWMU4
.

>

닉 아트만
+1 (330) 558-1230

나는 distutils에서 일하지 않습니다. 하지만 그렇다면 왜 요즘 사람들은 어쨌든 distutils를 사용할까요? 이 스레드는 distutils를 사용하여 이미 설치된 패키지에 관한 것입니다. 이에 대한 솔루션은 이미 이 스레드의 앞부분에서 언급되었습니다 .

@AddoSolutions 당신이 요구하는 바로 그 변화를 setuptools

그래서 내가 이 스레드에 있는 이유는 내가 바닐라로 자주 작업하기 때문입니다.
CentOS 7 상자에 특히 docker compose를 설치합니다. 센트OS
pip와 함께 제공되며 문제는 설명 된대로 이러한 오류가 발생한다는 것입니다.
위에.

저는 개인적으로 Python 사용자가 아니며 docker compose를 사용하고
그것에 셔틀. 개인적으로 setuptools의 차이점을 모르겠습니다.
및 distutils, CentOS python이 기본적으로 설치되어 있다고 생각합니다.
설치시 yum 사용?

두 가지: yum 패키지가 다음을 포함하도록 업데이트될 수 있습니까?
올바른 메타데이터? 또는 이 오류가 발생하면
메시지는 무엇을 해야 하는지에 대한 더 유용한 정보를 제공합니까? 대신처럼
distutils에 대한 비교적 비밀스러운 메시지
pip 나는 그것이 무엇인지조차 모릅니다) "길
pip가 설치된 것은 권장하지 않습니다. 다음으로 제거하는 것이 좋습니다.
x를 수행한 다음 x를 사용하여 다시 설치합니다." 그럴 것 같아
문제가 있는 사람의 수를 크게 줄입니다.

생각?

참고: 나는 그 차이를 파헤칠 수 있다는 것을 완전히 알고 있으며 아마도 그렇게 할 것입니다.
그러나 미래의 사용자를 위해 이것을 요구하고 또한 감사합니다.
칠면조 :)
2018년 11월 22일 목요일 오후 1:19 Ronny Pfannschmidt [email protected]
썼다:

@AddoSolutions https://github.com/AddoSolutions 당신이 요구하는 바로 그 변화
for는 setuptools라고 불립니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.

이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/pypa/pip/issues/5247#issuecomment-441099032 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ADrjCTBfoKjBuYdceDeBM0bunByQ2bxJks5uxuq2gaJpZM4TWMU4
.

>

닉 아트만
+1 (330) 558-1230

wrt yum 패키지의 업데이트 - 그것은 거의 배포판의 일입니다 - 그리고 그것은 그것을 하지 않았지만 어떤 경우에는 패키지 자체도 가지고 있지 않습니다

엔터프라이즈 배포판의 경우 - 상황이 너무 구식입니다 - 공급업체와 함께 해결하십시오 - 오픈 소스 업스트림은 이에 대한 권한이 없으며 엔터프라이즈 배포판에서 선택한 지원 부담을 감당할 필요가 없습니다 - 따라서 공급업체에 문의하십시오

잡았다. 따라서 이 경우 pip 패키지는 CentOS에서 유지 관리됩니다.
pip 그룹이 아닌 그룹?
2018년 11월 22일 목요일 오후 5:38 Ronny Pfannschmidt [email protected]
썼다:

yum 패키지의 업데이트를 작성하십시오.
배포 - 아직 하지 않았지만 패키지도 없습니다.
어떤 경우에는 스스로

엔터프라이즈 배포판의 경우 - 정말 고통스럽게 구식입니다 -
공급업체와 함께 해결하세요. 오픈 소스 업스트림은 권한이 없습니다.
그것은 당신의 선택에 대한 지원 부담을 감당할 필요가 결코 없어야합니다
엔터프라이즈 배포판 - 공급업체에 문의하십시오.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/pypa/pip/issues/5247#issuecomment-441129627 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ADrjCZAQ-ZBmpkm7izyKkE0WymSoT6M1ks5uxyd2gaJpZM4TWMU4
.

>

닉 아트만
+1 (330) 558-1230

@AddoSolutions 문제는 pip가 아니라 다른 패키지입니다. pip는 단순히 가식을 중단하고 정말 나쁜 것에 대한 지원을 중단했으며 이제 엔터프라이즈 배포판과 같은 나쁜 행위자에 대해 문제가 발생합니다. 따라서 엔터프라이즈 측면에서 패키지를 분류해야 합니다. 배포판 및 공급업체와 함께

참고로 - 임의의 최신 버전이 아닌 시스템(공급업체에서 관리)에서 pip를 사용하라는 메시지가 표시될 수 있습니다.

wxPython 대해 이 오류가 발생했습니다.

'wxPython'을 제거할 수 없습니다. distutils가 설치된 프로젝트이므로 어떤 파일이 해당 프로젝트에 속하는지 정확히 확인할 수 없으므로 부분 제거만 가능합니다.

sitepackages 아니라 distpackages (이해가 됨)에 있지만 폴더에서 파일을 삭제하는 것이 옳지 않다고 느꼈습니다.

apt 를 통해 설치했기 때문에 apt remove --autoremove python-wxgtk3.0 하면 내 시스템에서 패키지가 제거됩니다.

이것은 "우리의 문제가 아닙니다. 다른 사람이 해결합니다."는 pip에서 예상되는 것입니다. 소프트웨어는 패키지 충돌을 관리하는 척하지도 않습니다. 많은 시스템에 컨테이너를 배포할 수 있는 일부로 이 메시지를 받았습니다.

해결 방법을 제공해주신 분들께 감사드립니다. 이번에는 "pip install --upgrade pip" 이전에 "pip install docker" 순서를 변경했습니다. 향후 문제(예: 데이터 손상)가 발생하지 않기를 바랍니다.

내가 읽은 내용은 가상 환경을 사용하여 환경의 이상함으로부터 스스로를 보호해야 한다는 것입니다. 하지만 지금은 --user 플래그를 추가하여 이 문제를 해결할 수 있었습니다.

pip3 install -r requirements.txt --user

https://pip.pypa.io/en/stable/reference/pip_install/#cmdoption - 사용자

또한 호환될 수 있으므로 환경/ distutils 의해 설치된 임시 종속성의 정확한 버전으로 작업을 시도할 수 있습니다. 내 예에서 Pipenv는 awscli==1.15.85 및 apache-airflow==1.10.1 의 일시적인 PyYAML 종속성을 3.13으로 해결하지만 시스템에는 이미 3.11이 설치되어 있습니다. 내 로컬 개발 시스템에서 선언된 종속성을 살펴보면 3.11이 다음 두 가지 모두에 적합합니다.

$ pipenv graph | egrep 'airflow|awscli|PyYAML'
apache-airflow==1.10.1
    - PyYAML [required: >=3.0, installed: 3.13]
awscli==1.15.85
  - PyYAML [required: >=3.10,<=3.13, installed: 3.13]

간단한 pipenv install PyYAML==3.11 는 PyYAML을 3.11에 고정하고 두 패키지를 만족스럽게 만듭니다.

$ pipenv install PyYAML==3.11
Installing PyYAML==3.11…
...
Locking [packages] dependencies…
✔ Success!

$ pipenv graph | egrep 'airflow|awscli|PyYAML'
apache-airflow==1.10.1
    - PyYAML [required: >=3.0, installed: 3.11]
awscli==1.15.85
  - PyYAML [required: >=3.10,<=3.13, installed: 3.11]

My Pipfile / Pipfile.lock은 이후 pipenv install --deploy --system 사용하여 Ubuntu 14.04LTS에 깔끔하게 설치됩니다.

또한 확인했는데 PyYAML==3.11 가 python3-yaml 3.11-3build1을 통해 설치되었으며 이는 우리가 EC2에서 실행할 때 광범위하게 사용하는 cloud-init 18.4-0ubuntu1~16.04.2의 직접적인 종속성입니다. 18.04 LTS와 18.10은 모두 PyYAML 3.12와 함께 제공되며 19.04만 PyYAML 과 함께 제공됩니다. 이

즉, 시스템 종속성과 환경 문제를 어떤 대가를 치르더라도 피하십시오. pipenv 및/또는 virtualenv 합니다.

다음 단계를 사용하여 이 문제를 해결했습니다.

1. 축소 버전,
   pip install --upgrade --force-reinstall pip==9.0.3
2. 패키지를 다시 설치하려고 했습니다.
   pip install xxx --disable-pip-version-check
3. 마지막으로 pip의 최신 버전을 복구합니다.
   pip install --upgrade pip

이것은 나를 위해 잘 작동했습니다. 그러나 이후에 pip를 업그레이드하면 설치된 패키지에 문제가 발생합니까?

@s-eswar 지금까지 패키지에 대한 문제는 발견되지 않았지만 pip 설치 패키지의 상위 버전을 사용하는 경우 하위 버전을 다시 설치하거나 확인하는 상황에서 종속성 문제가 발생할 수 있습니다. 항상 낮은 버전을 사용하는 것이 좋습니다. 예를 들어, 핍 9.0.3.

@s-eswar 지금까지 패키지에 대한 문제는 발견되지 않았지만 pip 설치 패키지의 상위 버전을 사용하고 하위 버전을 다시 설치하거나 확인하는 경우 종속성 문제가 발생할 수 있는 한 가지 상황이 발생할 수 있습니다. 항상 낮은 버전을 사용하는 것이 좋습니다. 예를 들어, 핍 9.0.3.

@wangxf1987 하지만 동일한 구성의 ML 라이브러리를 사용하는 경우 업그레이드/낮은 버전 사용과 관련된 오류가 발생하지 않습니다.

@s-eswar prefect가 하위 버전에서 작동하는지 ML 라이브러리가 확실하지 않습니다. pip=9.0.3을 사용하면 최신 버전의 Kubernetes에서 작동합니다. 최신 버전의 pip가 필요한지 또는 개발 환경에서 테스트해야 하는지 여부는 요구 사항 파일을 확인해야 합니다.

pip 8 이후로 문제의 원인이 되었기 때문에 이 작업을 중단하려고 했지만 당시 너무 많은 사람들에게 영향을 미쳤기 때문에 초기 시도가 취소되었습니다. pip 10을 사용하여 distutils 패키지를 제거하려는 시도를 마침내 중단했으며 이제 여기에서 볼 수 있는 것처럼 사용자에게 문제를 보고합니다.

"이제 사용자에게 문제를 보고합니다" 라는 부분이

Dist 패키지 제거 및 실행

sudo rm -rf /usr/lib/python3/dist-packages/yaml

sudo rm -rf /usr/lib/python3/dist-packages/PyYAML-*

distutils에서 폴더 제거 작업

최신 버전으로 업그레이드하면 문제가 해결되지만 pip는 아이러니한 문제를 야기합니다.

해결책은 수동으로 제거하는 것이므로.../anaconda3/lib/python3.*/site-packages/로 이동하여 패키지의 모든 파일과 폴더를 삭제하십시오.

@라모나미스 sudo pip install --ignore-installed PyYAML

이것은 나를 위해 성공적으로 업그레이드했습니다.

이것은 imutils에서도 작동했습니다.

pip install --upgrade imutils --ignore-installed imutils

다음 단계를 사용하여 이 문제를 해결했습니다.

1. 축소 버전:
   pip install --upgrade --force-reinstall pip==9.0.3
2. 패키지 재설치 시도:
   pip install xxx --disable-pip-version-check
3. 마지막으로 pip의 최신 버전을 복구합니다.
   pip install --upgrade pip

그것은 나를 위해 작동합니다, 감사합니다!

다음 단계를 사용하여 이 문제를 해결했습니다.

1. Reduced version:
   `pip install --upgrade --force-reinstall pip==9.0.3`

2. Tried to re-install package:
   `pip install xxx --disable-pip-version-check`

3. At last, recover the latest version for pip:
   `pip install --upgrade pip`

이것은 나쁜 해결책입니다. 지금은 아무것도 할 수 없습니다.

Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python3-pip : Depends: python-pip-whl (= 9.0.1-2.3~ubuntu1) but 9.0.1-2.3~ubuntu1.18.04.1 is to be installed
               Recommends: python3-dev (>= 3.2) but it is not going to be installed
               Recommends: python3-setuptools but it is not going to be installed
               Recommends: python3-wheel but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
E: Could not read response to hello message from hook [ ! -f /usr/bin/snap ] || /usr/bin/snap advise-snap --from-apt 2>/dev/null || true: Success

지금 이 스레드를 잠그고 있습니다. @pfmoore 의 초기 의견은 여기에서 모든 것을 다룹니다. 이 스레드의 나머지 부분은 지원 요청이나 유지 관리자에 대한 직접적인 남용으로 누설되었습니다.