Pip: 기본값은 --user

이것은 pypa 설치 지침에서 무엇을 의미합니까?

현재 루트 또는 관리자 액세스에 대한 언급은 각주에 있으므로 지침은 기본적으로 동일하게 유지됩니다( get-pip 가 자동으로 --user 로 기본 설정된다고 가정). 변경 사항은 현재 사용자에게만 적용되는 설치로 끝날 것임을 설명하기 위한 것입니다.

--user 변경 사항에 관계없이 현재 지침은 데비안과 같은 일부 배포판이 Surepip을 비활성화하고 있으므로 pip를 얻는 방법으로 찾지 않아야 한다고 설명해야 합니다.

장기적으로 저는 그들이 계속 활성화할 것이라고 확신합니다. 그들은 단지 그것을 수행하는 방법을 알아내고 있을 뿐입니다.

이 문제는 pip가 기본적으로 패키지를 관리해야 하는 위치에 대한 것으로 설명되지만 거의 더 중요한(적어도 나에게) 이것은 간접적으로 get-pip 가 기본적으로 pip를 배치하는 위치에 관한 것입니다.

이것은 altinstall'd Python과 어떻게 상호 작용합니까?
특히 https://github.com/yyuu/pyenv 와 같은 도구로 설치되는 것과 같은

사용자 체계는 .local/lib/pythonX.Y/site-packages 이므로 동일한 주/부 버전으로 여러 파이썬을 관리하는 경우 엉망이 될 수 있습니다.

실제 파이썬을 관리하는 이와 같은 도구의 경우 pip를 전역 모드에 고정하는 것이 적합합니다.

redhat/fedora 버그 추적기 https://bugzilla.redhat.com/show_bug.cgi?id=662034#c10 관련 문제

Fedora/RedHat PATH=$PATH:$HOME/.local/bin:$HOME/bin 가 이미 /etc/skel/.bash_profile 에 있는 것 같습니다. 이렇게 하면 --user 로 설치된 항목이 최소한 bash 사용자(기본 셸)에 대해 기본적으로 계속 표시됩니다. 다른 배포판에 이미 이 기능이 있습니까?

내가 아는 Windows에 대해 특별히 다른 점은 없습니다. 그러나 우리는 사람들의 PATH에 표준 Python 디렉토리만 가지고 있습니다. 사용자별 스크립트 디렉토리를 얻는 것이 특히 쉬울 것이라고 기대하지 않습니다. 그리고 기술적인 어려움도 있을 수 있습니다. 잘 모르겠습니다. %LOCALAPPDATA% 와 같은 사용자 수준 환경 변수를 시스템 수준 %PATH% 넣어도 작동합니다 :-(

나는 이것을 서두르는 것에 반대합니다. 사용자 설치에 대한 더 많은 경험이 있고 문제를 먼저 해결할 수 있을 때까지 기다리는 것이 좋습니다. 나는 그것이 닭과 달걀의 문제라는 것을 알고 있지만, 변화를 서두르는 것이 도움이 된다고 보지 않습니다.

또한 Windows 모자를 쓰고 있는 상태에서 sudo를 부주의하게 사용하는 것이 어리석은 일을 하는 것이 나쁘다는 것을 아직 해결하지 못한 Unix 사용자를 더 어렵게 만드는 것은 그다지 좋은 정당화가 아니라고 말하고 싶습니다. .

나는 이것이 시스템 Python에서 pip를 실행할 때만 적용된다고 가정합니다.

Windows의 다른 점은 시스템 제공 Python 패키지와 함께 제공되는 *nix와 같은 Python 제공 시스템이 없다는 것입니다. :)

나는 특별히 이것을 서두르고 싶지도 않다. 토론을 시작하고 싶었을 뿐입니다.

이것은 루트로 무언가를 설치하는 것이 기본적으로 시스템 사이트 패키지로 가야 한다고 생각하기 때문에 sudo pip install 를 입력하는 사람들에게는 실제로 영향을 미치지 않습니다. 이것은 권한이 없는 사용자로 실행할 때 --user 를 사용하도록 사람들을 안내합니다. 지금 당신이 얻는 것은 일반 사용자로서 pip install 권한 오류가 발생한다는 것입니다. 우리가 그 메시지를 개선하여 --user 를 제안하더라도 여전히 최고의 UX는 아닙니다.

Fedora 직원 중 한 명과 이야기하면서, 이를 수행할 수 있는 방법은 권한 확인을 구현하는 것입니다. site-packages 디렉토리에 쓸 수 있는 권한이 있으면 권한이 있는 사용자이고 pip가 전역 Python에 설치합니다. 그렇지 않으면 권한이 없는 사용자이고 --user 에 설치됩니다.

Windows가 진행되는 한, 기본적으로 Python을 권한이 없는 디렉터리에 설치하기 때문에 일반적으로 문제를 피합니다. 따라서 pip는 전역적으로 설치할 때 UAC를 트리거하지 않습니다. 누군가가 대신 Program Files에 설치하도록 변경하면 UAC는 pip를 실행할 때 트리거됩니다(이것도 괜찮음). 설치 프로그램에서 사용자별 설치를 선택하면 어떻게 되는지 잘 모르겠습니다.

Paul이 언급했듯이 Windows의 PATH에는 아직 _user_ scripts 디렉토리(전역 디렉토리만)가 포함되어 있지 않으므로 이는 확실히 고려할 가치가 있습니다.

POSIX 측면에서 큰 장벽이 보이지 않습니다. 이 UX 아이디어는 어떻게 들리나요? 휠 기반 설치의 경우 설치 대상 디렉토리에 대한 권한을 확인하고 사용자에게 쓰기 권한이 없으면 대신 --user 설치를 수행할 것인지 묻는 프롬프트를 표시합니까? 새로운 "--global" 또는 "--system" 플래그는 "no" 응답을 강제합니다.

그리고 미래의 어느 시점에서 권한이 전역 설치에 적합하지 않은 경우 프롬프트를 건너뛰고 단순히 --user로 가정할 수 있습니다.

프롬프트(--no-input의 경우 제외)는 아마도 전환 단계에 적합할 것입니다. 기본적으로 위치는 사람들에게 권한이 있는 위치에 있기 때문에 권한을 확인하면 Windows에서도 작동할 수 있다고 생각합니다. t 그들에게 권한을 부여합니다.

본질적으로 이것은 우리의 실패 모드를 훨씬 더 좋게 만듭니다.

sudo의 부주의한 사용을 아직 해결하지 못한 Unix 사용자를 더 어렵게 만듭니다.
어리석은 일을 하는 것은 나쁜 일입니다.

sudo 및 보안은 실제로 부차적인 문제입니다.
이것은 주로 시스템 파이썬에서 OS 패키징과 pip 간의 충돌을 방지하는 것입니다.
현재 Linux 사용자는 종종 불가능한 상황에 처해 있습니다.

1. OS 명령: 'OS pkg mgr을 사용하십시오. roque pip 설치 패키지( get-pip 'd pip 포함)'로 시스템을 감염시키지 마십시오.
2. 현실: "OS 패키지(pip 포함)가 너무 오래되었고 일부 패키지의 업그레이드를 얻기 위해 배포판의 실험적 릴리스로 업그레이드할 수 없습니다. 나는 불량품이 됩니다...."

또 다른 단계는 get-pip.py --user 할 수 있고 --user virtualenv (및 wheel 및 twine (virtualenv가 아닌 경우)

FWIW, 배포판 공급업체도 현상 유지를 문제로 간주하고 핵심 OS 구성 요소에 영향을 주지 않고 선택적인 업그레이드를 수행하기 위한 도구를 개선하기 위한 다양한 방법을 찾고 있습니다. 그러나 이러한 노력은 다양한 성숙 단계에 있고 최종 사용자를 위한 일관된 크로스 플랫폼 솔루션을 원하기 때문에 업스트림 측면에서 해결할 가치가 있습니다.

Unix에서 배포판과 협력하는 데 도움이 되도록 변경하는 데 문제가 없습니다. Windows가 아닌 Unix의 기본값을 --user 로 설정하는 것이 허용된다면 괜찮습니다. 저는 Unix의 나쁜 경험에서 Windows의 나쁜 경험으로 전환하는 것을 좋은 절충안으로 보지 않습니다. 그리고 아직 Windows의 --user 가 황금기를 맞이할 준비가 되었다고 확신하지 못합니다.

Windows에서 pip _is_를 실행할 때 UAC를 트리거하는 것은 실제로 의미하는 바가 상승된 콘솔 창을 제외하고 pip가 실행되지 않는다는 것입니다. pip 사용자가 "OK"라고 말할 수 있는 멋진 프롬프트가 표시된다는 의미는 아닙니다. 불행히도 GUI 앱이 작동하는 방식은 이뿐입니다...

@pfmoore pip install 디렉토리에 쓰기 권한이 없을 때 Windows의 사용자 경험은 어떠해야 한다고 생각하십니까?

FWIW Windows 여부에 따라 이것을 선택 사항으로 만드는 데 전적으로 동의합니다. "사이트 패키지 폴더에 쓸 수 있는 권한이 있습니까" 체크가 설치의 99%에서 달성되지 않는지, 그리고 --user에 설치하는 것이 더 나은 경험인지 궁금합니다. site-packages 디렉토리에 대한 쓰기 권한이 없는 경우의 비율입니다.

즉, 제안이 전역 설치를 사용자 설치로 대체하지 않는 권한을 확인하면 권한 오류가 --user 설치로 대체됩니다.

제안이 전역 설치를 사용자 설치로 대체하지 않습니다.
권한 오류를 --user install로 대체하고 있습니다.

알겠습니다. 하지만 권한 확인 아이디어(#1048)가 가장 쉬운 일이 아님을 기억하십시오.

Wheel 케이스에서는 매우 쉬울 것이고 sdist로 99.9% 케이스를 덮을 수 있습니다. 이것은 정말 펑키한 일을 하는 setup.py의 문제일 것입니다.

pip install 무언가를 하고 디렉토리에 쓸 권한이 없을 때 Windows의 사용자 경험은 어떠해야 한다고 생각하십니까?

글쎄, site-packages 디렉토리에 쓸 수 있는 것은 Windows에서 매우 드물기 때문에 질문이 실제로 얼마나 관련이 있는지 잘 모르겠습니다. 그러나 그런 일이 발생하면 "시스템 사이트 패키지를 쓸 수 없습니다 --user 를 사용하려고 했습니까?"라는 오류가 발생했습니다. 현명한 접근이 될 것입니다.

사실, 유닉스에서도 그게 더 나을 것이라고 생각합니다. 쓰기 가능성에 따라 동작을 전환하는 것은 기이하고 쓰기 가능한 디렉토리에서 개인적으로 구축한 Python에 --user 를 사용하는 것이 올바른 접근 방식인지 여부는 분명하지 않습니다(그러나 저는 그러한 설정에 대한 경험이 정확히 없기 때문에 나는 그 의견을 뒷받침할 것이 아무것도 없다.)

제안: 위와 같이 --user 를 제안하는 오류로 시작하십시오. 사람들이 --user 를 더 일반적으로 사용하고 더 많은 경험이 있으면 기본값을 전환하는 것을 고려해 보겠습니다.

Paul이 제안한 접근 방식은 대략 제가 염두에 두었지만 오류 메시지를 표시하는 대신 예/아니오 프롬프트가 표시됩니다. 이 두 가지 접근 방식에는 장단점이 있습니다(대부분 다른 스크립트에서 호출할 때 실패하는 방식과 관련됨).

Python에 sys.localprefix와 같은 것을 추가할 수 있습니까(여기서 python-dev 참조)?
Sys.localprefix는 기본적으로 sys.prefix입니다. 배포판은 접두사를 정의하는 것과 같은 방식으로 정의할 수 있습니다(예: 접두사 = '/usr', localprefix='/usr/local'). Pip 및 easy_install은 sudo로 사용되는 경우 설치할 위치로 sys.localprefix를 사용하고 충분한 권한이 없는 경우 --user로 폴백합니다.

우리는 Fedora 17에서 "gem install"을 사용하여 이와 같은 작업을 수행했으며 Ruby 개발자는 일반적으로 이에 대해 매우 만족했습니다. 그래서 저는 공유할 생각입니다.

• "gem install foo"는 uid != 0인 경우 "foo"를 ~/somedir에 설치합니다.
• "gem install foo"는 uid == 0인 경우 "foo"를 /usr/local/somedir에 설치합니다.
• "yum install rubygem-foo"는 RPM 패키지 "foo"를 /usr/somedir에 설치합니다.

사용자 권한에 따라 install dir을 선택하는 것은 사람들에게 매우 혼란스러울 것이라고 생각합니다. "pip install foo"는 루트가 아닌 모든 사용자에게 동일한 방식으로 작동해야 합니다. 대다수의 사용자를 고려한다면 그들은 자신의 집에 "pip install"을, 시스템 전체 디렉토리에 "sudo pip install"을 원할 것입니다. 따라서 위와 같이 uid를 기반으로 하는 것이 가장 좋은 방법이라고 생각합니다. 루트는 아니지만 시스템 전체 디렉터리에 설치하려는 사용자에게는 항상 --target 옵션이 있습니다.

@bkabrda $PATH에 스크립트를 추가하는 것에 대해 걱정하지 않는 한 쉽게 선택할 수 있습니다. 거기에서 무엇을 했습니까?

@dstufft 가 언급한 @Ivoz , Fedora에는 이미 PATH에 $HOME/.local/bin이 있으므로 모든 것이 기본적으로 작동합니다(스크립트에 대해).

Slavek의 제안은 POSIX 시스템에 대해 나에게 좋게 들립니다. 컨테이너에서 실행되는 항목이 컨테이너 외부에서 완전히 다른 것이더라도 uid 0이라고 생각할 수 있기 때문에 컨테이너와도 잘 작동해야 합니다.

Windows의 경우 정답이 무엇인지 잘 모르겠습니다. 비록 그것이 어느 정도 존재하지만(pip install 대 MSI 설치 프로그램) 시스템 패키지 관리자와 논쟁을 벌이는 것과 동일한 문제가 없으며 Python 3.4에서도 설치 프로그램의 선택적 PATH에 추가 합병증이 있습니다. 수정은 사용자별 디렉토리가 아닌 전역 Scripts 디렉토리만 추가합니다.

Windows는 또한 Python이 기본 위치(제어되지 않음)에 설치되었는지 아니면 프로그램 파일(변경하려면 UAC 권한 상승이 필요함)에 설치되었는지에 따라 이상합니다.

@rkuska 가 제안한 "localprefix" 아이디어는 간단하고 쉬워 보입니다. 또한 @bkabrda 가 제안하는 접근 방식이 정말 마음에 듭니다. 특히 python 3.x를 기본 python으로 만드는 Arch와 같은 배포판의 경우 더욱 그렇습니다.

한 가지 더 주의할 점은 Arch는 Debian과 마찬가지로 3.4.0 릴리스에서 surepip을 비활성화했습니다(대부분 우리는 최신 버전의 setuptools 및 pip를 제공하기를 원하지만 번들 버전은 오래되었을 수 있음). 그것에 대한 팁.

@lvoz
Arch의 경우 $HOME 아래에 PATH에 대한 경로를 추가하지 않았지만 여전히 괜찮다고 생각합니다. 사용자에게 추가하도록 알려주는 Ruby용 위키 항목 이 이미 있습니다.

단순히 비활성화하는 것보다 Arch 및 Debian 개발자가 Slavek이 시스템 버전에서 휠을 재구성하고 가상 환경에 설치하도록 Slavek이 패치 작업을 하는 데 도움이 된다면 좋을 것입니다.

참고로, 우리는 이미 Fedora의 Copr 빌드 시스템에서 Python 3.4 RPM 빌드를 작동하고 있습니다. 우리가 이에 접근하는 방법에 대해 더 알고 싶다면 코드 등을 살펴보고 debian-python ML에서 Barry Warsaw [2]와의 토론을 참조하십시오.
(우리 패치를 업스트림으로 제안하기 전에 여전히 약간의 사랑이 필요하지만 다운스트림 ATM에서는 모든 것이 잘 작동합니다.)

[1] http://copr-fe.cloud.fedoraproject.org/coprs/bkabrda/python-3.4/
[2] https://lists.debian.org/debian-python/2014/03/msg00046.html

죄송합니다. AFAIK Arch는 결코 휠을 지원하지 않으며, 우리는 surepip이 패키지 관리자를 호출하도록 하고 싶지도 않습니다.

surepip의 경우, 사용자에게surepip을 사용하여 pip를 설치하지 말라고 경고하는 것이 좋을 것입니다.

우리의surepip은 패키지 관리자를 호출하지 않습니다. 간단히 말해서, Fedora의surepip은 시스템 패키지된 setuptools와 pip가 항상 존재하도록 의존합니다(우리의 python3 패키지는 의존성 루프를 생성하지만 우리는 그것을 처리할 수 있습니다). 그리고 사용자가 새로운 virtualenv를 생성할 때 다시 포장합니다 system setuptools 및 pip를 바퀴에 넣고 새 virtualenv에 설치하십시오.
우리는 주제에서 약간 벗어나기 시작했습니다. 그래서 이 논의를 다른 곳에서 계속해야 할 것 같습니다...

@felixonmars 이는 Arch venv에서 Debian과 동일하게 손상되었음을 의미합니까?

알겠습니다. 설명 감사합니다. 아이디어를 얻은 것 같습니다. 내가 무엇을 할 수 있는지 알아보고 이에 대해 debian-python에서 후속 조치를 취하겠습니다.

@dstufft 예, 번들 버전이 시스템 버전 대신 설치되었습니다.

@bkabrda 따라서 시스템 Python으로 pip를 호출하는 경우 문제를 해결하려면 이 경우 virtualenv/venv를 특수 케이스로 지정해야 합니다(세상의 끝이 아님). 그러나 이것은 또한 모든 Python이 시스템 Python이라고 가정한다는 의미이기도 합니다. 심지어 사용자가 https://github.com/yyuu/pyenv (이것이 실제로 Python을 실행하는 방법)를 사용하여 홈 디렉토리에 설치한 경우에도 마찬가지입니다. 그래서 잘 모르겠지만 그래서 권한 확인을 생각하게 된 것입니다.

@dstufft 가 말한 것과 마찬가지로 pyenv 와 같은 도구를 사용하여 루트가 아닌 파이썬을 저글링할 때 root 가 전역 설치(여기서 "global" != "시스템")

Fedora 17에서 "gem install"을 사용하여 이와 같은 작업을 수행했습니다.

페도라 17용 gem의 rpm이 이것을 배포판 해킹으로 가지고 있다는 말입니까? 아니면 gem 자체에 이 논리가 있습니까?

한 가지 생각은 pip가 pip를 패키징하는 배포판에서 켤 수 있는 "시스템 친화적 모드"를 제공해야 하거나 사용자가 pip를 시스템 관리 파이썬에 설치하고 있음을 알 때 켜야 한다는 것입니다. 그렇지 않으면 pip는 일반적인 전역 기본 논리를 수행합니다.

아 @felixonmars 방금 https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/python , 당신이하고있는 모든 것이 --without-ensurepip 를 호출하는 것이라면 괜찮습니다. . 이렇게 하면 venv 모듈에 대해 surepip 모듈이 그대로 유지됩니다. Ubuntu(Debian?)가 현재 가지고 있는 패치는 실제로surepip 패키지 자체에서 rm -rf 를 호출하므로 venv 내에서 호출할 수 없습니다.

사용자 설치를 기본값으로 설정하는 것은 2년 전에 Nick이 제안했거나 더 오래 전에 다른 사람이 제안했지만 스레드가 여러 방향으로 진행되어 성과가 없었습니다. 주요 장애물은 IIRC 이전 버전과의 호환성이었지만 요즘에는 sysadmins와 pip 사용자가 virtualenv/pip/setuptools 업데이트에 대해 좋든 나쁘든 주의하는 데 더 익숙할 수 있습니다. 그 토론이 distutils-sig 또는 pypa-dev에서 발생했는지 기억나지 않습니다.

카탈로그 서명: https://mail.python.org/pipermail/catalog-sig/2013-February/004773.html

@dstufft 아, 알겠습니다... 하지만 시스템적으로 설치된 패키지가 있는 동안 번들(아마도 이전) 버전을 설치하는 것이 여전히 잘못되었다고 생각합니다. :)

@felixonmars 음 , 문제는 시스템 패키지를 virtualenv afaik에 설치할 수 없다는 것입니다. :) (그리고 가능하더라도 시스템 패키지와 virtualenv 내부에서 원하는 것과 다른 문제가 있을 수 있음)

@dstufft 그것이 Slavek의 rewheel이 시작되는 곳이지만 약간 주제에서 벗어났습니다. :)

예, https://lists.fedoraproject.org/pipermail/python-devel/2014-March/000583.html 의 마지막 비트를 확인하십시오 :(

@dstufft 감사합니다!

여기서 토론을 계속해야 하는지 확실하지 않습니다. 왜냐하면 우리는 Arch에서 pip를 풀지 않았기 때문에 문제가 되지 않아야 하고 rewheel은 사용 가능한 휠을 생성해야 하기 때문입니다. :)

@dstufft 우리가 아마도 virtualenv 및 아마도 pyenv를 특수 케이스로 지정해야 할 필요가 있다는 말이 옳습니다. 이는 보기 흉해 보입니다. pyenv에 익숙하지 않다는 것을 인정해야 하므로 지금 당장은 이에 대한 "적절한" 솔루션이 생각나지 않습니다. 좀 더 자세히 살펴보고 생각해볼 생각입니다.

Fedora의 "gem install"에 대한 @qwcode 는 다운스트림 패치입니다. TBH Fedora의 Rubygems를 오랫동안 만지지 않았지만 마지막으로 확인했을 때 다운스트림에만 있었습니다.

이 문제에 대한 링크를 python [1]의 관련 버그에 게시했습니다. 이 토론을 python core로 이동하여 pip 뿐만 아니라 easy_install 및 python setup.py install 로컬 설치를 위한 구성 가능한 위치를 가지려면 pip가 ( 예) uid==0 인 경우 sys.localprefix dir 및 @bkabrda가 언급한 대로 uid!=0 인 경우 사용자 dir에 설치합니다.

당분간은 기본적으로 사용자 dir에 pip를 설치하는 것이 좋습니다.

[1] http://bugs.python.org/issue1298835

Nick이 지적했듯이 나는 토론을 issue1298835에서 pypa-dev [1]로 옮겼습니다.
[1] https://groups.google.com/forum/#!topic/pypa -dev/r6qsAmJl9t0

기본값은 --user

좋은 생각!

pip install foo 는 파일 권한이 없기 때문에 오류가 발생합니다. 이로 인해 사람들은 대신 시스템 Python에 전역적으로 설치되는 sudo pip install foo 를 실행합니다.

그것보다 더 나쁘다. 많은 사람들(예: 대학 컴퓨터 네트워크 사용자)은 sudo 권한이 없습니다. 권한 오류로 pip가 실패하면 다음 중 하나가 수행됩니다.

1. 관리자에게 이메일을 보내 패키지를 설치하도록 요청하십시오. 그것은 모두에게 느리고 지루합니다.
2. 포기하고 패키지 없이 하십시오.

특히 경험이 많거나 정보가 풍부한 경우에만 pip install --user 을 시도합니다.

'--user 기본값'에 대해 결정을 내리게 된다면 덜 방해가 되는 대안을 고려해야 합니다.

1. --user로 대체(권한 오류로 인해 설치가 실패한 경우)
2. (권한 오류로 인해 설치가 실패하는 경우) 사용자에게 (친한 큰 글자로) --user를 시도하도록 권장합니다.

나는 실제로 한동안 모든 설치에서 --user 를 사용해 왔지만 일반적으로 사람들은 이 옵션을 인식하지 못합니다. 옵션을 잊을 때마다 권한 오류가 표시되는 것이 짜증난다는 데 동의합니다. 사용자 설치가 conda와 호환되지 않는 것으로 나타났습니다(conda/conda#448).

3.5가 기본적으로 Program Files(수정하려면 관리자 권한이 필요함)에 설치하는 것이 기본이기 때문에 사람들이 Windows에서 훨씬 더 자주 Windows에서 이를 실행하기 때문에 이것을 되살리고 싶습니다.

"권한 오류 시 --user로 대체" 옵션이 가장 좋으며 제거 시 "--user로 기본 설정 및 시스템으로 대체" 옵션을 추가하고 --system 또는 --system-only 옵션을 추가할 수 있습니다. 폴백을 방지하기 위해. 의도적으로 관리자 권한으로 pip를 실행하는 사용자는 예상대로 시스템을 설치하게 되며 현재 권한이 없는 사용자에게는 오류가 발생하므로 여기에는 이전 버전과의 호환성 문제가 없다고 생각합니다.

내 목표는 정보가 없는 사용자가 오류 없이 pip install spam; python -c "import spam" 를 수행할 수 있도록 하는 것입니다( --user 로 다시 시도할 때 경고가 표시될 수 있음).

나는 최근에 특히 #2403과 #2401이 최근에 열렸기 때문에 sudo pip install 의 사용에 대해 생각하게 했고 이것이 권한 문제 외에 시스템을 자주 중단시킬 수 있는 방법에 대해 생각하게 만든 이후로 최근에 이것에 대해 생각했습니다.

이를 위해 더 나은 최종 목표가 --user 가 기본값이 아니고 마법의 권한 검사가 없고 --global , --system 와 같은 새 플래그를 추가하는 것이 아닌지 궁금합니다. 또는 --no-user 는 이전 동작을 복원합니다. 이것은 설치 방법/위치에 관계없이 동일한 동작을 갖기 때문에 사람들에게 설명하기가 더 쉽습니다.

자, 그것이 우리가 가고 싶은 길이라고 결정한다면, 오늘날 우리가 있는 곳에서 어떻게 그 지점에 도달할 것인가의 문제가 여전히 남아 있습니다. 분명히 어떤 시점에서 기본값을 전환하든 상당히 큰 변화가 일어나므로 상당히 긴 리드 타임이 필요합니다. 그렇게 하기로 결정했다면 가장 좋은 방법은 --user --global 와 같은 새 옵션을 추가한 다음 하나 또는 다른 옵션은 구성되지 않았으며 우리가 이야기한 권한 확인 마법을 수행하고 마법이 --global 동작을 사용하기로 결정했다면 매우 큰 비추천 경고를 발생시킬 것입니다. 이 사용 중단 경고는 우리가 발표한 다른 사용 중단 경고보다 훨씬 더 오래 지속됩니다. 이는 동작의 상당히 큰 변화가 될 것이기 때문입니다. 매직 폴백을 끄고 미래 동작을 구현하여 사람들이 오늘 그 동작을 얻을 수 있도록 하는 옵션도 추가하고 싶습니다.

또 다른 중요한 질문은 설치하려는 Python에 사용자 사이트가 활성화되어 있지 않음을 감지한 경우 어떻게 해야 하는지입니다. 이 경우에는 단순히 --user 가 오류이고 해당 Python의 경우 기본값을 --global 로 대체합니다. 이것은 내가 자동으로 믿는 virtualenv/venv를 다룰 것이며 누군가가 완전히 컴파일된 Python을 사용하여 "더 무거운" 가중치 격리 환경을 원하는 경우 site.py 를 패치하여 ENABLE_USER_SITE 를 False 로 설정할 수 있습니다.

+1, 나는 --system에 투표할 것입니다.

나는 당신이 이것을 좋아할 것이라고 확신합니다. Ubuntu 기본값이 변경되었습니다.

https://launchpad.net/ubuntu/+source/python-pip/1.5.6-4ubuntu1

2015년 2월 9일 오후 4시 41분에 Donald Stufft는 다음과 같이 썼습니다.

이를 위해 더 나은 최종 목표는 --user 가
기본적으로 마법의 권한 검사가 없으며 --global 와 같은 새 플래그를 추가합니다.
--system 또는 --no-user 이전 동작을 복원합니다. 이
상관없이 같은 행동을 할 것이기 때문에 사람들에게 설명하기가 더 쉽습니다.
어떻게/어디에 물건이 설치되는지.

--system 는 실제로 일부 Python에만 적용되기 때문에 잘못된 것이라고 생각합니다. 다음에는 적용되지 않습니다.

• Windows의 파이썬
• pyenv 설치된 Python
• Conda가 설치된 Python
• Nix 설치된 Python
• 사용자 정의 컴파일된 Python.

이것은 _only_ Python이 시스템에서 배송되는 *nix 시스템에만 적용됩니다. 나는 --global 가 그 깃발에 대해 훨씬 더 나은 이름이라고 생각합니다.

그리고 FML, 왜 Debian/Ubuntu는 예상 사용 사례를 깨는 무작위 패치를 지속적으로 추가해야 한다고 생각합니까?

따라서 Ubuntu 패치가 되돌려지면 여기서 수정되는 일정은 어떻게 됩니까? 일주일/한 달/3개월/6개월/년...?

고정이 무엇을 의미하는지에 따라 다릅니다.

잠시 동안 2개의 게시물이 있는 아이디어를 사용하고 있다고 가정하면(여전히 다른 pip 개발자의 승인이 필요함) 다음이 적용되는 전환 계획을 매우 빠르게 얻을 수 있습니다.

• --user 가 전달되면 우리는 _항상_ 사용자 사이트 패키지에 설치합니다.
• --global (또는 무엇이든)이 전달되면 우리는 _항상_ 글로벌 사이트 패키지에 설치합니다.
• 둘 다 전달되지 않으면 다음과 같은 폴백 메서드를 구현합니다.
  
  
  
  • 우리가 가상 환경에 있는지 감지하고 그렇다면 --global 가 전달된 것처럼 작동합니다.
  
  
  • 사용자 사이트 패키지가 비활성화되어 있으면 --global 가 전달된 것처럼 작동하는지 감지합니다.
  
  
  • 유효 사용자에게 sys.path 쓰기 권한이 없는지, --user 가 전달된 것처럼 작동하지 않는지 감지합니다.
  
  
  • 마지막으로, 다른 모든 탐지 방법이 실패하면 --global 가 전달된 것처럼 행동하고 미래의 어느 시점에서 이것의 동작이 변경되고 대신 --user 에 설치된다는 비추천 경고를 인쇄합니다.
  
  

이것은 누군가가 시스템 Python에 sudo pip install foo 을 사용하는 것을 막지는 않지만, 어느 시점에서 이것이 --user 를 의미할 것이라는 경고를 출력하고 명시적으로 --global 을 사용하기 시작하라고 알려줍니다.

• --user 가 전달되면 우리는 _항상_ 사용자 사이트 패키지에 설치합니다.
• --global (또는 무엇이든)이 전달되면 우리는 _항상_ 글로벌 사이트 패키지에 설치합니다.
• 두 옵션 모두 전달되지 않으면 다음과 같은 폴백 메서드를 구현합니다.
  
  
  
  • 가상 환경에 있는지 감지하고 가상 환경에 있으면 --global 가 전달된 것처럼 작동합니다.
  
  
  • 사용자 사이트 패키지가 비활성화되어 있으면 --global 가 전달된 것처럼 작동하는지 감지합니다.
  
  
  • 마지막으로 --user 를 기본값으로 사용합니다.
  
  

그러나 첫 번째 동작에서 두 번째 동작으로 이동하려면 상당히 긴 타임라인이 필요합니다. 이는 모든 소프트웨어(예: 소금, 요리사, 꼭두각시) 또는 배포 스크립트(예: 전 세계 수천 개의 프로젝트에 구워진 맞춤형 Fabric 스크립트)의 문제를 해결하는 정말 중요한 주요 변경 사항이 될 것입니다. sudo pip install <foo> 는 글로벌 Python에 설치됩니다. 사람들이 경고를 볼 수 있도록 긴 시간을 주어야 하며 실제로 해당 동작이 필요한 경우 명시적인 --global 플래그를 전달하도록 소프트웨어와 스크립트를 수정해야 합니다.

나는 Donald의 제안이 좋은 계획이라고 생각하지만, pip 팀이 그 접근 방식을 채택하기로 결정한다면 CPython에 3.5 릴리스 차단 문제를 제출하여 Windows의 경로에 전역 스크립트와 함께 사용자별 스크립트 디렉토리를 추가해야 합니다. 하나. 3.5에서 기본적으로 Program Files에 설치하는 스위치와 함께 이를 추가하면 관리자 권한 없이 설치하는 원하는 동작이 계속 "그냥 작동"해야 합니다.

pip 구성 파일을 통해 기본 설치 위치를 변경할 수 있는 것도 유용할 수 있으므로 기본 설정이 아직 변경되지 않은 경우에도 사람들이 자신의 시스템에서 "기본적으로 사용자별"을 선택할 수 있습니다. (예: "default-install=user" 대 "default-install=global")

@dstufft : 내가 필요한 경우 우분투 버그에 대해 설명한 대로 제안을 구현할 수 있게 된 것을 기쁘게 생각합니다. 트렁크에서 해당 동작을 얻으면 현재 우분투 패치를 백포트하고 물론 이것으로 교체합니다.

도움이 필요하면 계속 알려주세요.

@dstufft 의 계획에 +1입니다. 명시된 이유로 --global 를 이름으로 사용하겠습니다. 우리는 지금 충분히 오랫동안 울타리에 앉아 있었습니다. 가자.

Python 3.5가 Windows의 PATH에 사용자 사이트 디렉토리를 추가한다는 @ncoghlan 의 제안에 대해 O'n 및 +1입니다. 이 전환을 위해 더 이상 걸림돌이 되지 않도록 합시다.

나는 또한 @dstufft 의 계획에 대해 +1 이고 --global 에 대해 +1 이지만 sudo pip install foo 에 --global $ 가 필요한지 여전히 궁금합니다. 사실 루트가 사용자 사이트 패키지를 가질 필요가 있습니까? 기본적으로 사이트 패키지를 해제하도록 특별한 경우 루트를 사용할 수 있습니까? ( sudo pip install foo 를 지금처럼 작동하게 하려면)

현재 상태에서 루트에 --user 를 사용하는 사람을 본 적이 없지만 실제로 그러한 사용 사례를 알고 있는 사람이 있다면 알고 싶습니다.

나에게 일어난 한 가지 생각은 사용자 사이트 디렉토리가 설치된 여러 버전의 Python에서 어떻게 작동합니까?

Python 2.7 및 3.4(Python 3.4의 기본 Python)에서 pip install pytest --user 를 수행하면 py.test 명령이 실행되는 버전은 무엇입니까? 나는 두 개의 설치가 서로를 덮어쓰게 되어 "마지막 하나가 이기는" 상황이 될 것이라고 의심합니다. 이는 좋지 _않습니다_. 또한 "마지막이 승리"이고 3.4 버전 이후에 2.7 버전을 설치하는 경우 3.4를 다시 기본값으로 설정하려면 어떻게 수정해야 합니까?

제거는 어떻습니까? 다음 시나리오를 고려하십시오(테스트되지 않음, 기본 랩톱이 손상되는 위험을 감수하지 않으려면 깨끗한 컴퓨터를 설정해야 하기 때문에).

    C:\Apps\Python34\python.exe -m pip install pytest --user
    C:\Apps\Python27\python.exe -m pip install pytest --user
    C:\Apps\Python34\python.exe -m pip uninstall -y pytest

첫째, 두 번째 명령이 기존 파일을 덮어쓴다는 경고를 표시하지 않은 이유는 무엇입니까? 아니면 그럴까요? 하든 하지 않든 내가 해야 할 일에 대한 선택권이 있습니까?

둘째, py.test.exe RECORD 파일의 값과 일치하지 않기 때문에 제거가 실패하지 않습니까? 실패하면 어떻게 제거합니까? 실패하지 않으면 내 Python 2.7 pytest 복사본이 손상됩니까(exe 삭제)?

그리고 마지막으로 (지금은!) 사용자 스크립트 디렉토리가 PATH의 시스템 스크립트 디렉토리 앞이나 뒤에 가겠습니까? IMO, 그렇지 않으면 사용자가 "기본 Python"이 되도록 요청하지 _않은_ Python에 패키지를 설치하면 "기본" Python의 시스템 사이트 패키지에 설치된 동일한 패키지를 무시할 수 있기 때문에 IMO가 따라야 합니다.

흠, 아마도 우리가 이 변경을 하기 전에 해결해야 할 몇 가지 미해결 질문이 있을 것입니다...

공유 Windows 사용자 스크립트 디렉토리의 이름 충돌은 공유 bin 디렉토리가 있는 POSIX 시스템에서 처리되는 것과 동일한 방식으로 처리될 것으로 예상합니다. Python 3은 설치된 패키지에 대해 규정되지 않은 스크립트 이름을 설치하지 않으므로 규정되지 않은 이름은 Python 2 버전을 나타냅니다.

시스템 설치 또는 사용자별 설치가 기본적으로 우선하는지 여부에 대해서도 마찬가지입니다. 사용자 스크립트 디렉토리를 시스템 디렉토리 뒤에 두십시오.

"Python 3은 설치된 패키지에 대해 정규화되지 않은 스크립트 이름을 설치하지 않습니다." - 아마도 pip 및 setuptools(Python 3에서)가 여기에서 설치하지 않는다는 것을 의미합니까? 그 도구에 대한 변경 사항입니까?

아, 그리고 헐. 내 근육 메모리는 기본 Python(3.4)에 설치하기 위해 "pip install foo"를 입력하도록 100% 훈련되었습니다. 다시 훈련하는 것은 지옥이 될 것입니다.

또한 Windows 사용자는 시스템 Python이 규칙을 만드는 Unix 사용자와 달리 "python"이 Python 2 또는 3을 의미하는지("이를 기본 Python으로 설정" 및 "PATH에 추가"를 통해) 선택할 수 있습니다. 따라서 Python 3.5를 기본으로 설정하고 싶다고 하면 "pip"(또는 다른 정규화되지 않은 이름)가 해당 버전을 참조하면 안 되는 이유는 무엇입니까? Windows에 Python 3.5만 설치된 사용자가 시스템 Python에 이름이 필요한 방식에 대한 Unix 문제 때문에 정규화되지 않은 이름을 사용할 수 없다는 것은 이상하게 보입니다. (Unix 제약 조건에 대한 내 설명이 정확하지 않은 경우 사과드립니다. 문제를 제대로 이해하지 못합니다.) 여러 Python 버전을 설치하는 사람들에게는 솔루션이 필요하지만 해당 솔루션은 하나의 버전만 필요한 대다수에게 영향을 미치지 않아야 합니다.

아마도 가장 간단한 대답은 사용자 사이트 패키지 디렉토리와 마찬가지로 사용자 스크립트 디렉토리의 버전이 지정되어야 한다는 것입니다.

아, 그리고 이 논쟁은 여기보다는 python-dev에 관한 것이어야 합니까? 그것은 더 일반적으로 사용자 사이트 디렉토리에 관한 것이기 때문입니까?

python-dev에서 Windows 사용자별 스크립트 디렉토리에 대한 PEP 370 디자인 토론을 다시 여는 것은 확실히 합리적일 것입니다. Windows의 전역 스크립트 설치는 Python 버전으로 범위가 지정되지만 사용자별 스크립트 설치는 그렇지 않다는 것이 이상합니다.

이는 두 수준(전역 또는 사용자별)에서 실행 파일에 대해 공유 네임스페이스를 일관되게 사용하는 POSIX의 상황과 대조되므로 런타임 시 이름 섀도잉을 통해서가 아니라 설치 시 이름 충돌이 나타날 가능성이 더 큽니다.

병렬 설치를 처리하는 일반적인 솔루션은 "-m" 스위치가 될 것입니다. 이렇게 하면 별도의 스크립트의 shebang 줄 내용을 추측하기 보다는 항상 호출하는 Python을 알 수 있습니다.

-m 를 이해했지만, 지난 시간에 문서화 방법의 맥락에서 제기된 강력한 선호도는 pip install foo 를 설치하는 표준 방법으로 취급해야 한다는 것이었습니다( -m 및 버전이 지정된 명령은 특수한 경우의 예외로 취급됩니다.

pip 매뉴얼은 대안조차 _언급_하지 않습니다(Windows에서 pip 자체를 업그레이드하기 위해 -m 를 사용하는 경우는 제외).

나는 pip 호출을 처리하기 위해 stdlib 패키지 문서에서 -m을 권장합니다.
병렬 Python 설치 다루기 - 이것이 유일한 호출 스타일입니다.
글로벌 설치, 사용자 설치 및 가상 설치를 위해 모든 플랫폼에서 작동합니다.
환경.

2015년 2월 9일 오후 7시 58분에 ncoghlan은 다음과 같이 썼습니다.

pip 구성 파일을 통해 기본 설치 위치를 변경할 수 있음
또한 사람들이 "기본적으로 사용자별"을 선택하도록 허용하여
기본값이 변경되지 않은 경우에도 자체 시스템
아직. (예: "default-install=user" 대 "default-install=global")

나는 이것을 좋아한다. 해결 방법에 대해 고민하고 있는 것 중 하나는
--user 기본값으로 마이그레이션하는 업스트림의 보다 보수적인 접근 방식,
pip 시스템을 안전하고 다른 것과 일관성 있게 만드는 경쟁 목표를 배포합니다.
도구. 예

https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1419695
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725848

기본값을 선택하기 위한 시스템 전체 구성 파일이 있는 경우
최소한 관련된 모든 기계는 동일할 것이고 배포판은 그렇지 않을 것입니다.
추한 델타를 수행해야합니다. 우리가해야 할 일은 변경하는 것입니다.
config 파일을 만들고 사용자에게 문서화합니다. 발생하는 문제는 다음과 같습니다.
우리가 처리해야 하지만 적어도 설명하기는 쉬울 것입니다.

Debuntu가 현재 사이트 전체에 pip.conf 파일을 설치한다고 생각하지 않습니다.
다시 확인).

https://pip.pypa.io/en/latest/user_guide.html#configuration

한 가지 합병증: Python 2 및 Python 3에 대해 서로 다른 pip 스크립트를 설치합니다.
그래서 우리는 다른 버전의 구성 파일이 필요하다고 생각합니다.
Python, 예: /etc/{xdg/pip/}/pip{2,3}.conf 또는 일부.

2015년 2월 10일 오전 1시 24분에 Paul Moore는 다음과 같이 썼습니다.

나에게 일어난 한 가지 생각은 사용자 사이트 디렉토리가
여러 버전의 Python이 설치되어 있습니까?

Debian/Ubuntu(모든 *nixes?)에서는 충돌이 없습니다.
라이브러리는 ~/.local/lib/pythonX.Y/site-packages에 설치됩니다.

그래도 ~/.local/bin에서 충돌이 발생합니다. 다음을 사용하여 패키지 설치
pip install --user foo 및 pip3 install --user foo 를 사용하는 스크립트 'foo'는
결국 ~/.local/bin/foo 스크립트를 방해합니다.

이 변경의 한 가지 단점은 Fedora가 기본적으로 ~/.local/bin 를 $PATH 에 추가하는 유일한 다운스트림 배포판이라고 생각한다는 것입니다. 사용자 사이트 패키지가 사이트 패키지 앞에 오는 것처럼). 이상적으로 다운스트림은 ~/.local/bin 가 기본적으로 $PATH 에 있도록 시스템을 수정할 수 있습니다.

2015년 2월 10일 오전 7시 24분에 Donald Stufft는 다음과 같이 썼습니다.

이 변경의 한 가지 단점은 Fedora가 유일한 다운스트림이라고 생각한다는 것입니다.
기본적으로 ~/.local/bin 를 $PATH 에 추가하는 배포판
사용자 사이트 패키지가 오는 것처럼 /usr/bin 및 /usr/local/bin 전에
사이트 패키지 전에). 이상적으로 다운스트림은
~/.local/bin 가 기본적으로 $PATH 에 있도록 시스템.

네, 하지만 이에 대해서는 별도로 결정할 수 있습니다. (또는 오히려 다운스트림
배포판은 그렇게 할 수 있습니다.)

(그리고 이것은 사용자처럼 /usr/bin 및 /usr/local/bin 앞에 와야 합니다.
사이트 패키지는 사이트 패키지보다 먼저 옵니다)

흠, @ncoghlan 은 방금 그 반대로 말했습니다. (Windows에서는 특히
컨텍스트) 사용자 스크립트 디렉토리는 _이후_ 시스템 디렉토리여야 합니다. 어느
사용자 스크립트 디렉토리의 버전이 없는 한 동의합니다. 만약
버전이 지정되어 덜 걱정됩니다. 하지만 그것은 아마도
Windows 사용자는 버전 없는 스크립트가 충돌하고
pip2/pip3와 같은 괴물, Unix 사용자가 가지고 있는 방식 ;-)

아, 그리고 스크립트를 방해하는 것은 --user 와 정확히 관련이 없는 보다 일반적인 문제입니다. Windows --global 설치를 제외한 모든 곳에서 동일한 문제가 존재합니다. 그 문제에 대한 해결책은 우리가 이 문제와 별도로 해결해야 하는 2차적 관심사/문제라고 생각합니다.

그래서 현재 생각:

• 제가 이전에 포스팅한 일반적인 아이디어에 대해 동의가 있는 것 같아서 그런 식으로 진행하고 싶다고 생각합니다.
• 우리는 --global 플래그를 사용할 것입니다.
• --user 에 설치하고 ~/.local/bin 가 $PATH 에 없으면 일종의 경고가 필요할 것입니다.
• 기본적으로 대체 동작을 비활성화하고 --global 또는 --user 로 하드코딩하는 일종의 default-install 옵션이 필요합니다.
• pip 6.0부터 /etc/ 에 머신별 구성 파일이 있지만 pip를 실행하는 Python 버전에만 해당되는 것은 아닙니다. 나는 그것이 다소 분리되어 있기는 하지만 좋은 기능이라고 생각합니다.

여전히 열려 있는 한 가지 중요한 질문이 있습니다. 누군가가 sudo pip install foo 를 하거나 site-packages 디렉토리에 쓸 수 있는 권한이 있는 경우 장기적으로 우리는 어떤 일이 일어나기를 원합니까?

내가 생각할 수있는 옵션은 다음과 같습니다.

1. --global 에 설치합니다. 이것은 가장 이전 버전과 호환되는 옵션이며 사용자가 입력할 때 기대하는 것을 나타냅니다. 그러나 많은 시스템에서 시스템 고장을 유발할 수 있는 전역 Python을 (조용히) 엉망으로 만든다는 단점이 있습니다.
2. --user 에 설치하면 깨진 시스템으로부터 보호할 수 있지만(제 생각에는?) 루트 사용자가 /root/.local/ 설치를 받을 것으로 예상하는 사람은 없을 것입니다.
3. 오류가 발생하여 사용자가 --user 또는 --global 수동으로 선택하도록 요구합니다.
4. 처음 두 옵션 중 하나를 선택하되 배포판에서 /etc/ 로 전환할 수 있는 스위치를 제공하여 세 번째 옵션을 활성화합니다.

네 번째 옵션이 가장 좋은 옵션일 수 있지만 모든 플랫폼/시나리오에서 동일하게 작동하고 모든 플랫폼에서 이해되는 솔루션을 찾을 수 있다면 먼저 다른 옵션 중 하나를 선택해야 한다고 생각합니다. 가능하다면 플랫폼 간 일관된 행동을 선호합니다.

"나는 쓰기 권한이 있습니다"라는 시나리오가 Windows의 모든 사람이 Python 3.5 이전 버전을 사용하거나 Conda를 사용하는 사람 또는 pyenv를 사용하는 사람이라는 시나리오가 될 것이기 때문에 세 번째 옵션은 나쁜 옵션일 가능성이 높다고 생각합니다. 오류를 발생시키는 것은 이러한 모든 경우에 잘못된 일처럼 보이며 부팅하기에 다소 사용자에게 친숙하지 않습니다.

그래서 저는 1과 2 사이에서 사람들이 (개념적으로) sudo pip install --global foo 하는 것이 얼마나 나쁜 습관이라고 생각하는지에 달려 있다고 생각합니다. Windows, Conda, pyenv 등에서는 "우리는 그것이 나쁜 습관이라고 생각하지 않습니다"라는 대답이 있다고 생각합니다. *nix에서는 "사용자가 시스템에 대해 원하는 작업을 수행할 수 있어야 하지만 "나쁜" 상황에서 사용자를 이끌 수 있는 레일을 제공해야 합니다.

그래서 그것에 대해 더 생각해보면, 나는 첫 번째 선택이 우리에게 올바른 선택이 되어야 한다고 생각합니다. 우리가 실제로 변경할 동작은 전역 디렉토리에 설치할 권한 없이 pip install foo --user 입력하면 오류를 발생시킵니다. 나는 그 경우에 오류를 발생시키는 pip에 의존하는 사람이 없을 것이라고 생각합니다. 또한 루트 사용자로서의 pip install --user 는 누구나 기대하거나 원하는 것이 아닐 가능성이 있으며 실제로는 사용자를 위한 발판을 만들고 있다고 생각합니다.

따라서 업데이트된 제안은 다음과 같습니다.

• --user 가 전달되면 우리는 항상 사용자 사이트 패키지에 설치합니다.
• --global 가 전달되면 우리는 항상 글로벌 사이트 패키지에 설치합니다.
• 둘 다 전달되지 않으면 다음과 같은 폴백 메서드를 구현합니다.
  
  
  
  1. 가상 환경에 있는지 감지하고 가상 환경에 있으면 --global 가 전달된 것처럼 작동합니다.
  
  
  2. 사용자 사이트 패키지가 비활성화되어 있으면 --global 가 전달된 것처럼 작동하는지 감지합니다.
  
  
  3. default-install 를 보고 존재하는 경우 이를 기반으로 --user 또는 -global 를 사용합니다.
  
  
  4. 유효 사용자에게 글로벌 사이트 패키지에 대한 쓰기 권한이 없는지, --user 가 전달된 것처럼 작동하지 않는지 감지합니다.
  
  
  5. 마지막으로 다른 모든 탐지 방법이 실패하면 --global 가 통과된 것처럼 행동합니다.
  
  

이것은 사용 중단 기간이 없음을 의미하며 --user 또는 --global 가 없는 경우 실행 중인 Python의 기능을 기반으로 최선의 추측을 시도할 것으로 예상됩니다. , 유효 사용자 및 구성된 기본 설치 방법.

(그리고 이것은 사용자처럼 /usr/bin 및 /usr/local/bin 앞에 와야 합니다.
사이트 패키지는 사이트 패키지보다 먼저 옵니다)

흠, @ncoghlan 은 방금 그 반대로 말했습니다. (Windows에서는 특히
컨텍스트) 사용자 스크립트 디렉토리는 _이후_ 시스템 디렉토리여야 합니다. 어느
사용자 스크립트 디렉토리의 버전이 없는 한 동의합니다. 만약
버전이 지정되어 덜 걱정됩니다. 하지만 그것은 아마도
Windows 사용자는 버전 없는 스크립트가 충돌하고
pip2/pip3와 같은 괴물, Unix 사용자가 가지고 있는 방식 ;-)

대본 이름이 충돌한다는 측면에서 생각조차하지 않습니다. $PATH 변수가 sys.path 와 다르게 작동하는 것은 완전히 잘못된 것이라고 생각합니다. 내가 아는 한 sys.path 의 순서는 stdlib > 사용자 사이트 패키지 > 글로벌 사이트 패키지입니다. some-script 의 순서가 global bin dir > user bin dir 이고 python -m some-script 가 사용자 사이트 패키지 > 글로벌 사이트 패키지라면 정말 혼란스러울 것 같습니다.

스크립트 디렉토리에 문제가 있는 경우(버전이 있는 경우와 없는 경우) 해당 문제를 수정해야 한다고 생각하지만 어떤 순서로 되어 있어야 하는지는 그다지 중요하지 않습니다 sys.path 는 매우 잘못되었습니다.

좋은 점, 우리는 $PATH가 sys.path를 따르고 (Windows 용어로) C:PythonXYScripts보다 %APPDATA%PythonXYScripts 이전에 C:PythonXYScripts를 사용한다고 가정하고 권장해야 합니다. python-dev 스레드에 대해 언급하겠습니다.

Donald의 최신 제안은 나에게 좋게 들립니다. "그래서 더 생각해보면..." 문단에 저도 100% 동의합니다.

Windows에서 PATH를 구성하는 것은 거의 불가능합니다. 시스템 전체 설치 프로그램은 시스템 전체 환경 변수만 구성할 수 있으며 확장을 포함할 수 없으므로 각 사용자에 대해 다른 경로를 설정할 수 없습니다. (사용자별 설치 프로그램이 수행할 수 있지만 이 경우 --global 가 성공하므로 필요하지 않습니다.)

또한 Windows의 깨진 PATH 처리로 인해 시스템 전체 설정이 _항상_ 사용자별 설정을 능가합니다. 이것은 pip.exe 가 항상 최신 시스템이나 사용자 Python이 아닌 최신 시스템 또는 사용자 Python으로 이동하도록 버전 없는 스크립트에 py.exe 실행 프로그램을 사용하는 것에 대해 (python-dev, IIRC에서) 반쯤 제안했습니다. 하나를 설치하고 (예) pip.exe -3.5 는 특정 버전 선택을 허용합니다.

이것이 실제로 작동하도록 하는 유일한 방법은 요청 시 PATH(배치 파일을 실행하는 바로 가기)를 구성하기 위해 Python 설치 프로그램이 배치 파일 설치를 시작하는 것입니다. 따라서 사용자가 가장 먼저 입력하는 것은 activate-py35 이고 PATH는 3.5에 대해 올바르게 구성됩니다. vcvarsall.bat 상황에 빠지고 싶지 않기 때문에 이에 대해 매우 고민하고 있지만 동시에 현재 설치 위치에 대해 가정하거나 레지스트리를 통해 이동하려고 시도하는 스크립트에 유용할 것입니다. 그것을 찾기 위해.

배치 파일을 실행하는 바로 가기

내 생각에 이것은 "Python 3.5(32비트) 명령 프롬프트" 바로 가기입니다. Visual Studio 사용자는 병렬을 인식해야 합니다.

나는 Windows에 대해 그 모든 의미를 완전히 이해할 만큼 충분히 알지 못하지만 foo 스크립트를 설치하는 pip install foo 가 즉시 실행될 수 없는 상황으로 되돌아가는 것은 꽤 기분이 나쁩니다. 명령줄에서 foo 로 실행됩니다. 우리가 --user 에 설치하고 기본적으로 경로에 없다면 그것은 나에게 꽤 큰 회귀처럼 느껴집니다.

버전이 지정되지 않은 스크립트에 py.exe 를 사용하는 것이 실제로 어떻게 작동하는지 그리고 실제로 문제를 해결할 수 있는지 여부를 정확히 이해하고 있는지 확신할 수 없습니다. 저는 개인적으로 오늘날과 같은 방식으로 스크립트를 작성하는 것과 관련이 없습니다. 따라서 _효과가 있으면_ 할 수 있다고 생각하지만 이에 대해 +1을 하기 전에 의미를 더 잘 이해해야 합니다.

Windows에서 PATH를 구성하는 것은 거의 불가능합니다. 시스템 전체 설치 프로그램은 시스템 전체 환경 변수만 구성할 수 있으며 확장을 포함할 수 없으므로 각 사용자에 대해 다른 경로를 설정할 수 없습니다.

오, 쉿. 나는 그것을 잊었다.

배치 파일을 실행하는 바로 가기
내 생각에 이것은 "Python 3.5(32비트) 명령 프롬프트" 바로 가기입니다. Visual Studio 사용자는 병렬을 인식해야 합니다.

... 모든 것에 대해 기본적으로 Powershell을 사용하는 사람들에게는 끔찍합니다.

그러나 스크립트 foo를 설치하는 pip install foo를 명령줄에서 foo로 즉시 실행할 수 없는 상황으로 되돌아가는 것은 꽤 기분이 나쁩니다.

동의. 이것은 잘못된 회귀이며 해결해야 합니다. 누군가가 방법을 생각할 수 있기를 바랍니다 :-)

버전 없는 스크립트에 py.exe를 사용하는 것이 실제로 어떻게 작동하는지 정확히 이해하고 있는지 잘 모르겠습니다.

py.exe 와 다소 관련이 있는 요점은 현재와 같이 특정 하드 코딩된 Python 인터프리터를 호출하는 대신 exe 래퍼가 "무엇을 기본값입니다" 어떻게든 (레지스트리, py.exe ini 파일, Python %PATH%가 제공하는 모든 것, ...). 그래도 버전이 지정된 사용자 스크립트 디렉터리(파일이 서로 덮어쓰이거나 패키지가 설치되지 않은 인터프리터로 실행되는 파일을 방지하기 위해)가 여전히 필요하기 때문에 이것이 어떻게 도움이 될지 잘 모르겠습니다. %PATH%의 올바른 위치에 넣을 수 없습니다.

... 모든 것에 대해 기본적으로 Powershell을 사용하는 사람들에게는 끔찍합니다.

방금 시도했고 동일하게 보이고 동작하는 activate-py35.bat 및 activate-py35.ps1 파일을 쉽게 만들 수 있습니다(즉, 모두가 activate-py35 를 작성하고 경로를 업데이트하면 됨). 여전히 이상적이지는 않지만 최악의 상황에서 최선일 수 있습니다.

버전 없는 스크립트에 py.exe를 사용하는 것이 실제로 어떻게 작동하는지 정확히 이해하고 있는지 잘 모르겠습니다.

py.exe 와 다소 관련이 있는 요점은 exe 래퍼가 현재와 같이 특정 하드 코딩된 Python 인터프리터를 호출하는 대신 "무엇을 기반으로 인터프리터를 동적으로 선택해야 하는지 기본" 어떻게든

"somehow"는 py.exe 가 들어오는 곳입니다. 동일한 규칙을 사용해야 합니다. 런처가 자체 이름을 확인하도록 업데이트된 경우 python.exe 를 시작하는 대신 'scripts\\{}{}.{}.exe'.format(argv[0], major_version, minor_version) ( argv[0] 등의 적절한 확장자 트리밍 포함)를 시도하고 시작할 수 있습니다. 그런 다음 설치 프로그램은 버전이 없는 런처에 대해 완전히 버전이 지정된 런처와 다른 파일(오늘부터 변경되지 않음)을 사용해야 하지만 해당 파일은 새 이름을 가진 일반 py.exe 입니다. (이것은 pip-script.py 파일의 옛날에는 훨씬 더 간단할 수 있었지만 지금은 그것들이 사라졌습니다...)

그러나 당신이 말했듯이 PATH는 여전히 문제입니다. 나는 좋은 해결책이 없으며 나쁜 해결책도 많지 않습니다. 환경 변수는 실제로 설치 프로그램이 아니라 관리자 또는 사용자가 구성하기 위한 것입니다.

더 나은 사용자 경험을 위해 스크립트 설치 방법을 조정할 수 있습니다. .exe 및 .py 파일이 결합된 모든 것이 균형이며 단일 .exe 파일이 있기 때문에 사용자에게 더 나은 기능을 제공합니다. 그러나 나는 pip install foo && foo 에 대한 최고의 이야기를 얻는 것이 그 특정한 것보다 더 중요하다고 생각하므로 .exe 와 .py 를 다시 분리해야 하는 경우에는 그것이 좋은 답변을 위한 좋은 절충안.

.exe / .py 분리가 가장 작은 문제입니다 :)

저는 실제로 activate-py35 아이디어를 준비 중입니다. 저는 PATH에 Python을 추가하는 설치 프로그램의 팬이 아니었고 py -m pip 명령은 실제로 주목을 받지 못했습니다(예를 들어 Sphinx에서도 작동하지 않습니다). activate-py 가 작동하는 방식에 대한 자세한 설명을 작성하고 python-dev에 게시하여 견인력이 있는지 확인하겠습니다.

이 activate-whatever 파일은 가상 환경 내부의 파일과 유사합니까? $PATH 에 가상 환경을 추가하는 대신 실제 Python을 추가하는 것을 제외하고는?

예, 거의 동일합니다. python-dev에서 저는 -x.y 매개변수를 사용하여 py.exe 에 전달하고 sysconfig 를 사용하여 경로를 가져오도록 제안했습니다.

확인. 나는 Windows 사용자가 아니기 때문에 이것이 Windows 사용자에게 얼마나 나쁜지에 대한 의견이 없습니다. 그것은 절대적으로 끔찍하게 들리지 않지만(어쩌면?) Windows 지식이 저를 데려갈 수 있는 정도입니다.

2015년 2월 10일 오전 8시 2분에 Donald Stufft는 다음과 같이 썼습니다.

아, 그리고 스크립트를 방해하는 것은 그렇지 않은 더 일반적인 문제입니다.
정확히 --user 와 관련이 있습니다. 같은 문제는 어디에나 존재한다
Windows --global 설치 제외. 나는 그 문제에 대한 해결책이
이 문제와 별도로 해결해야 하는 2차 문제/문제입니다.

동의.

우리는 --global 플래그를 사용할 것입니다.

+1

--user 에 설치하고
~/.local/bin 가 $PATH 에 없습니다.

+1, 아마도 경고를 표시하지 않는 구성 옵션이 있습니까?

기본적으로 default-install 옵션이 필요합니다.
대체 동작을 비활성화하고 --global 또는
--user .

+1

pip 6.0 현재 /etc/ 에 시스템별 구성 파일이 있습니다.
그러나 이들은 실행 중인 Python 버전에만 국한되지 않습니다.
씨. 나는 그것이 다소 분리되어 있지만 좋은 기능이라고 생각합니다 (그리고
스크립트를 방해하는 문제를 해결하는 데도 손을 댈 수 있습니다.)

다음과 같은 검색 순서를 제안합니다.

• pipX.Y.conf
• pipX.conf
• pip.conf

/etc/xdg/pip 다음에 /etc에 루트(?)를 둡니다. 여기서 XY는 물론
major.minor 버전 번호. 먼저 찾은 사람이 이깁니다.

나는 여전히 하나의 중요한 미해결 질문을 봅니다. 장기적으로
누군가가 sudo pip install foo 또는 오히려 권한이 있는 경우
site-packages 디렉토리에 쓰시겠습니까?

"site-packages" 디렉토리가 하나만 있는 것은 아닙니다. 예를 들어,
Debian/Ubuntu에서는 sudo pip install 가 _ever_ 설치되는 것을 원하지 않습니다.
/usr/lib, 그러나 /usr/local/lib만. 그리고 잊지 마세요. 여기에 dist 패키지가 있습니다.
사이트 패키지가 아닙니다($reasons 때문에 ~/.local 제외).

이것은 때때로 (나조차도) 잊혀지는 정말 중요한 포인트입니다.
Donald는 사이트 로컬 디렉토리와
공급업체 로컬 디렉토리. 데비안에서 site-local은
/usr/lib/pythonX.Y/dist-packages 및 pip 명령이 이를 건드려서는 안 됩니다.
반면 공급업체 로컬은 /usr/local/lib/pythonX.Y/dist-packages이고
일부 시스템 관리자가 pip install을 위한 문서화되고 널리 사용되는 사용 사례
그 디렉토리로.

그래서 제가 제안하고 싶은 것은 이미 구성 파일 경로에 있기 때문에
이를 구성 가능하게 만드십시오. 예를 들어

• 전역_설치_디렉토리
• global_install_as_sudo(참/거짓)

1. --global 에 설치합니다. 이것은 가장 이전 버전과 호환되는 옵션입니다.
   사용자가 입력할 때 기대하는 것을 나타냅니다. 그러나 그것은
   많은 경우에 글로벌 Python을 (조용히) 엉망으로 만든다는 단점이 있습니다.
   시스템은 고장난 시스템을 유발할 수 있습니다.

위의 구성 가능성으로 이것은 Debian과 완전히 호환됩니다.
데비안 슈퍼유저는 sudo pip install 가 들어갈 것으로 예상합니다.
/usr/local/lib/pythonX.Y/dist-packages. 나는 그것을 "망친다"라고 말하지 않을 것입니다.
시스템"은 패키지 관리자를 손상시키지 않기 때문에
시스템에 설치된 패키지를 재정의합니다.
/usr/lib/pythonX.Y/dist-packages), 정의되고 문서화된 방식으로 수행합니다.

1. --user 에 설치하면 고장난 시스템으로부터 보호할 수 있습니다(제 생각에는?)
   하지만 루트 사용자가
   /root/.local/ 설치합니다.

예상하지 못한 일이라는 데 동의합니다.

1. 오류가 발생하고 사용자가 --user 또는
   --global 수동으로.

나는 괜찮지만 위의 구성 스위치를 참조하십시오.

1. 처음 두 가지 옵션 중 하나를 선택하되 배포판에서 다음을 수행할 수 있는 스위치를 제공하십시오.
   /etc/ 을 입력하면 세 번째 옵션이 활성화됩니다.

이봐, 정말 좋은 선택이야!

네 번째 옵션이 가장 좋은 옵션일 수 있지만
어떤 종류의 해결책을 찾을 수 있다면 먼저 다른 옵션 중 하나를 선택하십시오.
모든 플랫폼/시나리오에서 동일하게 작동하고 모든 플랫폼에서 의미가 있습니다.
가능한 경우 플랫폼 간 일관된 행동을 선호하기 때문입니다.

다른 플랫폼 정의 동작을 해도 괜찮습니다. 예를 들어 pip가
--dry-run 옵션은 최소한 사용자에게 진행 상황을 정확히 알려줍니다.
할 일과 장소.

세 번째 옵션이 나쁜 옵션일 가능성이 높다고 생각합니다.
권한"은 Windows의 모든 사용자가 사전에 있는 시나리오가 될 것입니다.
Python 3.5, Conda를 사용하는 사람 또는 pyenv를 사용하는 사람. 오류 발생
이 모든 경우에 하는 것이 잘못된 것처럼 보이며 다소 사용자입니다.
부팅에 비우호적입니다.

기본 구성이 --global install을 허용하는 것이라면 기쁠 것입니다.
권한이 있습니다. 나는 데비안이 그것을 바꿀 것이라고 생각하지도 않는다(아마도 다른 사람들은
다른 의견이지만 적어도 그것은 우리에게 선택권을 줍니다).

그래서 나는 1과 2 사이에서 연습이 얼마나 나쁜지에 달려 있다고 생각합니다.
우리는 사람들이 (개념적으로) sudo pip install --global foo 하는 것이라고 생각합니다.

데비안에서는 /usr/local/lib로 이동하는 한 예상되는 사용 사례입니다.
/usr/lib로 이동할 수 없습니다.

(이 모든 것은 외부 환경 BTW를 설명합니다.)

• --user 가 전달되면 우리는 항상 사용자 사이트 패키지에 설치합니다.

+1

• --global 가 전달되면 항상 글로벌 사이트에 설치합니다.
• 패키지.

글로벌 _vendor_ 패키지 == +1, 글로벌 사이트 패키지 == -1.

• 둘 다 전달되지 않으면 다음과 같은 폴백 메서드를 구현합니다.
  
  
  
  1. 가상 환경에 있는지 감지하고 가상 환경에 있으면 마치 가상 환경에 있는 것처럼 작동합니다.
     
     --global 가 통과되었습니다.
  
  

+1, 비록 venv 내부의 이 디렉토리의 이름이
/lib/pythonX.Y/사이트 패키지

1. 사용자 사이트 패키지가 비활성화되어 있는지 감지하고 비활성화된 경우 다음과 같이 작동합니다.
   --global 이(가) 통과되었습니다.

흠, 이건 잘 모르겠습니다.

1. default-install 를 보고 존재하는 경우 --user 를 사용하거나
   -global 를 기준으로 합니다.

+1

1. 유효 사용자에게 전역에 대한 쓰기 권한이 없는지 감지합니다.
   사이트 패키지 및 --user 가 전달된 것처럼 작동하지 않는 경우.

+1

1. 마지막으로 다른 모든 탐지 방법이 실패하면 --global 인 것처럼 행동합니다.
   통과되었다.

또한 확실하지 않습니다.

이는 사용 중단 기간이 없음을 의미하며 예상은 다음과 같습니다.
--user 또는 --global 부재
우리가 실행 중인 Python의 기능, 효과적인 사용자 및
구성된 기본 설치 방법.

합리적인 목표처럼 들립니다.

분명히 말씀드리자면, "글로벌 사이트 패키지"에 대해 이야기할 때 저는 주로 "distutils가 전 세계적으로 설치하도록 지시하는 모든 것"을 의미합니다. Python 자체에는 "공급업체 로컬" 대 "사이트 로컬" 구분이 없기 때문에 Python을 패치하지 않는 다운스트림에서 동일한 디렉토리가 됩니다. 그러나 데비안에서는 실제로 dist-packages 디렉토리가 될 것이고 "global"은 실제로 "site local"을 의미합니다. pip가 지원하기 위해 특별히 해야 할 일은 아니지만 Debuntu의 Python 패치에 의해 처리되기 때문입니다.

즉, Debuntu가 해당 구분을 지원하기 위해 distutils를 패치했기 때문에 pip는 이미 Debuntu의 /usr/local/../dist-packages/ 에 설치됩니다. 사용자가 일종의 플래그를 전달하지 않고 pip가 /usr/../dist-packages/ 를 엉망으로 만드는 유일한 경우는 pip가 거기에서 파일을 제거하는 것입니다(pip는 해당 디렉토리를 특별한 것으로 보지 않기 때문에 그냥 사물로 봅니다. sys.path ). 데비안은 제거를 방지하기 위해 pip를 패치했으며 이에 대한 실제 지원은 Python 업스트림에서 "공급업체 로컬" 사이트 패키지에 대한 실제 지원을 얻는 데 달려 있다고 생각합니다.

--user에 설치하고 ~/.local/bin이 $PATH에 없으면 일종의 경고가 필요할 수 있습니다.

이 경고는 얼마나 취약한가요? 절대경로로 바뀌나요? 대소문자를 구분하지 않는 파일 시스템에서 대소문자를 구분하지 않습니까? Windows에서 및/또는 동등하게 취급합니까? 심볼릭 링크는 어떻습니까?

스크립트를 설치하지 않는 패키지를 설치하는 경우 경고는 어쨌든 관련이 없습니다.

개인적으로 나는 경고가 득보다 실이 더 많을 것이라고 생각합니다.

--user 에 설치하고
~/.local/bin 가 $PATH 에 없습니다.

+1, 아마도 경고를 표시하지 않는 구성 옵션이 있습니까?

사람들이 조용히 할 수 있도록 Python 경고를 사용하도록 할 수 있습니다.
내장된 Python 경고를 사용합니다. 침묵할 필요를 느낀다면
모두.

pip 6.0 현재 /etc/ 에 시스템별 구성 파일이 있습니다.
그러나 이들은 실행 중인 Python 버전에만 국한되지 않습니다.
씨. 나는 그것이 다소 분리되어 있지만 좋은 기능이라고 생각합니다 (그리고
스크립트를 방해하는 문제를 해결하는 데도 손을 댈 수 있습니다.)

다음과 같은 검색 순서를 제안합니다.

• pipX.Y.conf
• pipX.conf
• pip.conf

/etc/xdg/pip 다음에 /etc에 루트(?)를 둡니다. 여기서 XY는 물론
major.minor 버전 번호. 먼저 찾은 사람이 이깁니다.

나는 이것이 이것과 접선적으로만 관련되어 있다고 믿기 때문에 이것을 #2417로 나눕니다.
논의.

나는 여전히 하나의 중요한 미해결 질문을 봅니다. 장기적으로
누군가가 sudo pip install foo 또는 오히려 권한이 있는 경우
site-packages 디렉토리에 쓰시겠습니까?

"site-packages" 디렉토리가 하나만 있는 것은 아닙니다. 예를 들어,
Debian/Ubuntu에서는 sudo pip install 가 _ever_ 설치되는 것을 원하지 않습니다.
/usr/lib, 그러나 /usr/local/lib만. 그리고 잊지 마세요. 여기에 dist 패키지가 있습니다.
사이트 패키지가 아닙니다($reasons 때문에 ~/.local 제외).

이것은 때때로 (나조차도) 잊혀지는 정말 중요한 포인트입니다.
Donald는 사이트 로컬 디렉토리와
공급업체 로컬 디렉토리. 데비안에서 site-local은
/usr/lib/pythonX.Y/dist-packages 및 pip 명령이 이를 건드려서는 안 됩니다.
반면 공급업체 로컬은 /usr/local/lib/pythonX.Y/dist-packages이고
일부 시스템 관리자가 pip install을 위한 문서화되고 널리 사용되는 사용 사례
그 디렉토리로.

그래서 제가 제안하고 싶은 것은 이미 구성 파일 경로에 있기 때문에
이를 구성 가능하게 만드십시오. 예를 들어

• 전역_설치_디렉토리
• global_install_as_sudo(참/거짓)

pip는 실제로 이것을 제어하지 않습니다(내 말은, 분명히 높은 수준에서는
파일을 이동하는 파일이기 때문에) distutils/sysconfig에서 가져옵니다.

나는 pip가 아마도 공급 업체-로컬 디렉토리를 건드려서는 안된다고 생각합니다.
--vendor 와 같은 일종의 플래그가 제공되어 벤더가 사용할 수 있습니다.
빌드 체인에서 pip. 이 개념은 실제로 debuntu 외부에 존재하지 않습니다.
지금 당장 그리고 그들의 패치가 이미 이것을 처리하고 있으므로 그것이 최고라고 생각하지 않습니다.
내가 말할 때
"글로벌 사이트 패키지" Debubuntu에서 /usr/local/.../dist-packages 를 의미했습니다.
Python이 Debuntu를 수락하는 경우 어느 시점에서 "site-local" 패키지
시스템 업스트림.

1. --global 에 설치합니다. 이것은 가장 이전 버전과 호환되는 옵션입니다.
   사용자가 입력할 때 기대하는 것을 나타냅니다. 그러나 그것은
   많은 경우에 글로벌 Python을 (조용히) 엉망으로 만든다는 단점이 있습니다.
   시스템은 고장난 시스템을 유발할 수 있습니다.

위의 구성 가능성으로 이것은 Debian과 완전히 호환됩니다.
데비안 슈퍼유저는 sudo pip install 가 들어갈 것으로 예상합니다.
/usr/local/lib/pythonX.Y/dist-packages. 나는 그것을 "망친다"라고 말하지 않을 것입니다.
시스템"은 패키지 관리자를 손상시키지 않기 때문에
시스템에 설치된 패키지를 재정의합니다.
/usr/lib/pythonX.Y/dist-packages), 정의되고 문서화된 방식으로 수행합니다.

예, "시스템 엉망"은 너무 가혹할 수 있습니다. 대부분 내 말은
sudo pip install foo 는 시스템이 foo 에 의존하고 있고
호환되지 않는 버전의 사물을 설치합니다. 그러나 같은 경우가 성립
기본적으로 `/usr/local``에 설치하는 모든 항목 에 대해 true입니다.

• --global 가 전달되면 항상 글로벌 사이트에 설치합니다.
• 패키지.

글로벌 _vendor_ 패키지 == +1, 글로벌 사이트 패키지 == -1.

이건 반대로 말씀하시는 건가요?

• 둘 다 전달되지 않으면 다음과 같은 폴백 메서드를 구현합니다.
  
  
  
  1. 가상 환경에 있는지 감지하고 가상 환경에 있으면 마치 가상 환경에 있는 것처럼 작동합니다.
     
     --global 이(가) 통과되었습니다.
  
  

+1, 비록 venv 내부의 이 디렉토리의 이름이
/lib/pythonX.Y/사이트 패키지

예, 다시 우리는 파이썬에게 그 디렉토리가 어디에 있는지 묻습니다. 우리는 그것을 계산하지 않습니다
따라서 "해당 디렉토리가 있는 위치"는 venv/virtualenv입니다.

1. 사용자 사이트 패키지가 비활성화되어 있는지 감지하고 비활성화된 경우 다음과 같이 작동합니다.
   --global 이(가) 통과되었습니다.

흠, 이건 잘 모르겠습니다.

사용자 사이트 패키지가 비활성화되어 있으면 이 문제를 해결할 방법이 없다고 생각합니다.
우리가 알 방법이 없기 때문에 우리가 거기에 설치해야한다고 생각하지 마십시오
비활성화가 사용자 사이트 패키지가 _is_ 없음을 의미하는 경우 또는 그 이유는 무엇입니까? 우리는 할 수 있습니다
없다고 가정합니다.

1. 마지막으로 다른 모든 탐지 방법이 실패하면 --global 인 것처럼 행동합니다.
   통과되었다.

또한 확실하지 않습니다.

이것은 기본적으로 다음과 같이 요약됩니다.

--user 플래그와 같이 --user를 사용해야 하는 이유를 찾지 못한 경우 또는
디렉토리에 쓸 수 있는 권한이 없으면 사용하지 마십시오. 이
--global 플래그 없이 sudo pip install foo 를 유지하는 것입니다.
일하고있는. 이것은 또한 이것이 깨지지 않는 가장 중요한 규칙임을 의미합니다.
sudo pip install foo 가 이런 식으로 작동할 것으로 예상하는 작동하는 소프트웨어입니다.

--user에 설치하고 ~/.local/bin이 $PATH에 없으면 일종의 경고가 필요할 수 있습니다.

이 경고는 얼마나 취약한가요? 절대경로로 바뀌나요? 대소문자를 구분하지 않는 파일 시스템에서 대소문자를 구분하지 않습니까? Windows에서 및/또는 동등하게 취급합니까? 심볼릭 링크는 어떻습니까?

스크립트를 설치하지 않는 패키지를 설치하는 경우 경고는 어쨌든 관련이 없습니다.

개인적으로 나는 경고가 득보다 실이 더 많을 것이라고 생각합니다.

다음과 같이 구현할 수 있습니다.

def user_bin_on_path():
    paths = os.environ.get("PATH").split(":")
    for path in paths:
        if os.path.realpath(path) == os.path.realpath(USER_BIN_DIR):
            return True
    return False

그런 것은 심볼릭 링크, 경로 구분 기호 등을 처리해야 한다고 생각합니다. 세부 사항에 악마가 있으며 다양한 플랫폼 간 코너 사례를 다룰만큼 정확하지 않을 수 있습니다.

나는 스크립트가 설치되어 있지 않다면 경고가 무의미하다는 데 동의합니다. 그리고 저는 스크립트를 설치할 때만 경고를 무시할 것이라고 말하고 싶었습니다.

기본 아이디어는 --user가 암시적인 pip install [--user] foo 와 같은 작업을 수행한 다음 foo 를 수행하고 에 대한 지침 없이 "명령을 찾을 수 없음"을 얻는 것을 원하지 않는다는 것입니다. 찾을 수 없는 이유. 최소한 경고는 PATH에 추가해야 함을 알려줍니다. 또한 Windows 사용자에게 사용자 디렉토리를 PATH에 수동으로 추가하도록(또는 이를 수행하기 위해 일부 스크립트를 실행) 프롬프트를 표시하는 데 도움이 될 수 있으며, 이는 Steve가 지적한 activate 스크립트의 필요성을 완화할 수 있습니다. 나는 그것이 여전히 시스템 값이 사용자 값보다 우선한다는 것을 의미한다고 생각하지만 PATH 및 sys.path의 순서가 여전히 반대이기 때문에 여전히 혼란스러울 수 있습니다.

도. realpath 이 경로를 정규화했다는 것을 잊었습니다. 예, 물론 충분히 잘 작동합니다.

나를 괴롭히는 것은 테스트가 실수로 문제를 발견한 경우 _if_ 사용자는 pip의 실수를 해결하기 위해 시스템을 변경하는 것 외에는 피할 방법이 없는 성가시고 잘못된 경고를 받는다는 것입니다. 그러나 제안하는 테스트가 충분히 강력하고 스크립트를 설치하는 경우에만 검사를 수행한다는 점을 감안할 때 문제는 무시할 수 있을 정도로 드물 것입니다.

알겠습니다. 여기에서 광범위한 합의가 이루어진 것 같습니다. 나는 다음 단계가 패치를 얻는 것이라고 생각합니다. 나는 가서 오늘 밤이나 내일 늦게 무언가를 얻으려고 노력할 것입니다.

2015년 2월 10일 오후 12시 14분에 Donald Stufft는 다음과 같이 썼습니다.

기본 아이디어는 --user가 암시적인 pip install [--user] foo 와 같은 작업을 수행한 다음 foo 를 수행하고
명령이 없는 이유에 대한 지침 없이 "명령을 찾을 수 없음"을 얻습니다.
설립하다.

Debian 및 아마도 다른 Linux에는 실제로 command-not-found 패키지가 있습니다.
사용자가 다음 명령을 호출하면 패키지를 설치하라는 메시지가 표시됩니다.
설치되어 있지 않습니다.

% 잉크스케이프
'inkscape' 프로그램이 현재 설치되어 있지 않습니다. 다음을 입력하여 설치할 수 있습니다.
sudo apt-get 잉크스케이프 설치

어쩌면 우리는 플랫폼을 지원하기 위해 그것에 연결할 수 있습니다.

2015년 2월 10일 오후 12시 6분에 Donald Stufft는 다음과 같이 썼습니다.

• --global 가 전달되면 항상 글로벌 사이트에 설치합니다.
• 패키지.

글로벌 _vendor_ 패키지 == +1, 글로벌 사이트 패키지 == -1.

이건 반대로 말씀하시는 건가요?

내 용어가 혼동될 수 있으므로 명시적으로 설명하겠습니다.

/usr/local/lib/pythonX.Y/dist-packages == +1
/usr/lib/pythonX.Y/dist-packages == -1

그러나 이전에 말했듯이 이것은 pip이 정말로 걱정할 필요가 있는 것이 아닙니다.
distutils에서 상속되고 Debuntu의 distutils가 패치되었기 때문에
옳은 일을 하기 위해.

1. 사용자 사이트 패키지가 비활성화되어 있는지 감지하고 비활성화된 경우 다음과 같이 작동합니다.
   --global 이(가) 통과되었습니다.

흠, 이건 잘 모르겠습니다.

사용자 사이트 패키지가 비활성화되어 있으면 이 문제를 해결할 방법이 없다고 생각합니다.
우리가 알 방법이 없기 때문에 우리가 거기에 설치해야한다고 생각하지 마십시오
비활성화가 사용자 사이트 패키지가 _is_ 없음을 의미하는 경우 또는 그 이유는 무엇입니까? 우리는 할 수 있습니다
없다고 가정합니다.

오, 무슨 말인지 이제 알겠어요. 그게 말이 되는 것 같아요. 내 걱정은 그것이
pip가 실제로 무엇을 할 것인지 예측하는 것이 더 어려울 수 있지만,
pip가 분명히 _tell_할 수 있도록 --dry-run 플래그를 사용하는 것이 좋습니다.
당신은 무엇을 할 것입니다.

1. 마지막으로 다른 모든 탐지 방법이 실패하면 --global 인 것처럼 행동합니다.
   통과되었다.

또한 확실하지 않습니다.

이것은 기본적으로 다음과 같이 요약됩니다.

--user 플래그와 같이 --user를 사용해야 하는 이유를 찾지 못한 경우 또는
디렉토리에 쓸 수 있는 권한이 없으면 사용하지 마십시오. 이
--global 플래그 없이 sudo pip install foo 를 유지하는 것입니다.
일하고있는. 이것은 또한 이것이 깨지지 않는 가장 중요한 규칙임을 의미합니다.
sudo pip install foo 가 이런 식으로 작동할 것으로 예상하는 작동하는 소프트웨어입니다.

내가 참조. 우리가 피하고 싶은 주요 사용 금지 사례는 다음과 같기 때문에 괜찮다고 생각합니다.

normal_user$ pip 설치 foo
이봐 당신은 권한이 없습니다
normal_user$ sudo pip install foo
이봐 당신은 방금 시스템을 BOOKED

"디렉토리에 쓸 수 있는 권한이 없다는 것은 --user" 규칙을 의미합니다.
그것을 처리합니다.

아, 명령을 찾을 수 없다는 사실을 잊어버렸습니다. 유용할 수 있습니다. 그건 그렇고, devubtu가 기본적으로 경로에 사용자 로컬 bin을 가지고 있다고 제안할 적절한 위치를 알고 있습니까?

2015년 2월 10일 오후 4시 5분에 Barry Warsaw [email protected] 에서 다음과 같이 썼습니다.

2015년 2월 10일 오후 12시 14분에 Donald Stufft는 다음과 같이 썼습니다.

기본 아이디어는 --user가 암시적인 pip install [--user] foo 와 같은 작업을 수행한 다음 foo 를 수행하고
명령이 없는 이유에 대한 지침 없이 "명령을 찾을 수 없음"을 얻습니다.
설립하다.

Debian 및 아마도 다른 Linux에는 실제로 command-not-found 패키지가 있습니다.
사용자가 다음 명령을 호출하면 패키지를 설치하라는 메시지가 표시됩니다.
설치되어 있지 않습니다.

% 잉크스케이프
'inkscape' 프로그램이 현재 설치되어 있지 않습니다. 다음을 입력하여 설치할 수 있습니다.
sudo apt-get 잉크스케이프 설치

어쩌면 우리는 플랫폼을 지원하기 위해 그것에 연결할 수 있습니다.

—
이 이메일에 직접 회신하거나 GitHub에서 확인하세요.

2015년 2월 10일 오후 1시 17분에 Donald Stufft는 다음과 같이 썼습니다.

아, 명령을 찾을 수 없다는 사실을 잊어버렸습니다. 유용할 수 있습니다. 그건 그렇고 당신은
devubtu에 사용자 로컬 bin이 있다고 제안할 올바른 위치를 알고 있습니다.
기본적으로 경로?

확실하지는 않지만 아마도 adduser 또는 passwd 패키지? 전자가 소유
/usr/sbin/adduser 및 후자는 /usr/bin/useradd를 소유합니다.

첫 번째 패스: https://github.com/pypa/pip/pull/2418

도움이 되실지 모르겠습니다만...

• ~/.local/bin은 많은 사람들의 $PATH에 없습니다. 이에 대해 할 수 있는 일이 있습니까?

일부 다른 프로젝트는 $PATH에 디렉토리를 추가하기 위해 /etc/profiled.d/ 를 사용합니다. 적어도 Antergos에서는 jre.csh, jre.sh, perlbin.csh, perlbin.sh를 볼 수 있습니다.

# Do not change this unless you want to completely by-pass Arch Linux' way
# of handling Java versions and vendors. Instead, please use script `archlinux-java`
setenv PATH "${PATH}:/usr/lib/jvm/default/bin"

# Do not change this unless you want to completely by-pass Arch Linux' way
# of handling Java versions and vendors. Instead, please use script `archlinux-java`
export PATH=${PATH}:/usr/lib/jvm/default/bin

# Set path to perl scriptdirs if they exist
# https://wiki.archlinux.org/index.php/Perl_Policy#Binaries_and_Scripts
# Added /usr/bin/*_perl dirs for scripts
# Remove /usr/lib/perl5/*_perl/bin in next release

[ -d /usr/bin/site_perl ] && setenv PATH ${PATH}:/usr/bin/site_perl
[ -d /usr/lib/perl5/site_perl/bin ] && setenv PATH ${PATH}:/usr/lib/perl5/site_perl/bin

[ -d /usr/bin/vendor_perl ] && setenv PATH ${PATH}:/usr/bin/vendor_perl
[ -d /usr/lib/perl5/vendor_perl/bin ] && setenv PATH ${PATH}:/usr/lib/perl5/vendor_perl/bin

[ -d /usr/bin/core_perl ] && setenv PATH ${PATH}:/usr/bin/core_perl

# If you have modules in non-standard directories you can add them here.
#export PERLLIB=dir1:dir2

# Set path to perl scriptdirs if they exist
# https://wiki.archlinux.org/index.php/Perl_Policy#Binaries_and_Scripts
# Added /usr/bin/*_perl dirs for scripts
# Remove /usr/lib/perl5/*_perl/bin in next release

[ -d /usr/bin/site_perl ] && PATH=$PATH:/usr/bin/site_perl
[ -d /usr/lib/perl5/site_perl/bin ] && PATH=$PATH:/usr/lib/perl5/site_perl/bin

[ -d /usr/bin/vendor_perl ] && PATH=$PATH:/usr/bin/vendor_perl
[ -d /usr/lib/perl5/vendor_perl/bin ] && PATH=$PATH:/usr/lib/perl5/vendor_perl/bin

[ -d /usr/bin/core_perl ] && PATH=$PATH:/usr/bin/core_perl

export PATH

# If you have modules in non-standard directories you can add them here.
#export PERLLIB=dir1:dir2

임의의 pip 사용자로서 이와 같은 사용자 경험 문제에 대해 작업하고 사용자 경험 개선 이정표에 캡처된 다른 것과 같은 작업에 대해 _고맙습니다_. 이 노력에 재정적으로 기여할 수 있는 곳이 있습니까?

제쳐두고, 저는 Homebrew 를 사용하고 brew install something 할 수 있고 권한에 대한 소란 없이 작동한다는 사실에 항상 감사했습니다.

Homebrew로 설치하는 데 sudo 가 전혀 필요하지 않은 이유를 이해하면 pip install --user something 하는 습관을 들이려고 했지만 역설적이게도 Homebrew는 distutils에서 보고된 버그로 인해 이를 비활성화합니다 .

OS X에서 Homebrew의 인기를 감안할 때 Homebrew와 pip install --user 의 이러한 비호환성을 조사하고 싶을 것입니다.

어쨌든 --user 를 기본값으로 만들 때 +1합니다.

빠른 후속 조치. Didier는 --user를 기본값으로 설정하는 Ubuntu의 pip에 대한 변경 사항을 생생하게 업로드했습니다. 나는 또한 그것을 대부분 허용했지만 지금은 그것이 실수라고 생각하고 그것을 wily로 되돌릴 예정입니다(그러나 아마도 SRU가 생생하게 변경되지는 않을 것입니다). 자세한 내용과 근거는 https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1460203 을 참조하세요.

사용자 대 시스템 구분이 플랫폼 차이 없이 이미 충분히 혼란스럽기 때문에 업스트림이 이 변경의 타이밍을 주도하도록 하는 데 +1입니다.

즉, Linux 배포판은 --global 지원이 업스트림 pip(pip 8?)에 도달하자마자 기본값을 --user로 뒤집기 시작하는 것이 합리적일 수 있습니다. per-venv installs는 잠재적으로 예측할 수 없는 부작용이 있는 나쁜 생각으로 잘 알려져 있습니다.

@warsaw 에게 개인적으로 말했지만 여기에서도 말할 것입니다.

나는 이 변경이 중요하다고 생각하며 마무리하기 위해 내 풀 리퀘스트에 다시 돌아올 계획입니다. 그러나 저는 여러 프로젝트에 걸쳐 있는 한 사람이고 지금 이 변화보다 Warehouse가 더 중요합니다. 왜냐하면 PyPI 레거시가 운영에 점점 더 부담이 되고 있고 가능한 한 빨리 이를 교체해야 한다고 생각하기 때문입니다. 따라서 pip에 대한 제 시간은 많은 변경 사항을 만드는 데 초점을 맞추는 것이 아니라 다른 기여자가 만드는 변경 사항과 릴리스 프로세스 항목을 안내하는 데 중점을 둡니다.

즉, 누군가가 이 기능이 더 빨리 출시되는 데 정말로 관심이 있다면 내 작업을 선택하고 완료할 수 있으며 나는 기꺼이 검토하고 병합할 것입니다. 나는 그것을 하고 싶어하고 변화에 대한 지침을 제공하고자 하는 누구와도 그것을 통해 이야기하게 되어 기쁩니다. 그렇지 않으면 나에게 더 시급한 항목을 완료할 때까지 기다릴 것입니다.

이 시점에서 반복할 가치가 있습니다.

'--user 기본값'을 선택하지 않으면 덜 방해가 되는 대안을 고려해야 합니다.

1. --user로 대체(권한 오류로 인해 설치가 실패한 경우)
2. (권한 오류로 인해 설치가 실패하는 경우) 사용자에게 (친한 큰 글자로) --user를 시도하도록 권장합니다.

FWIW, 이제 Python 3.5용 Windows 설치 프로그램이 사용자별 설치를 강력하게 권장하므로 pip에서 발생하는 이 변경 사항에 대해 그다지 걱정하지 않습니다. 새로운 기본값이나 대체(fallback)보다 배포판( --global 재정의 포함)에 대해 더 나은 구성 옵션을 만들 수 있습니다.

이 문제를 +1하고 작업해 주셔서 감사합니다. 우리는 현재 과학적인 Python 여름 학교를 운영하고 있으며 많은 사람들이 권한 문제에 직면했을 때 sudo pip install 했습니다.

FWIW 저는 기본적으로 --user 로 설정하거나 권한 오류로 인해 설치가 실패하면 --user 로 대체하는 것을 찬성합니다. 이 경우, 나는 그들에게 실패하고 다시 시도하는 방법을 말하는 것보다 그들이 한 일을 되돌릴 수 있는 지침을 제공하는 것을 선호합니다(예: We installed to your user directory. If you don't want this, then 'pip uninstall my_package' ).

--user로 인해 모의에 대한 많은 버그 보고서가 표시됩니다. 적어도 Ubuntu에서는 --user의 위치가 dist-packages 뒤에 있으므로 일반적인 종속성에 대해 설치된 pip가 실제로 사용되지 않습니다(예: 6) dist 패키지에 있습니다.

그들은 그것을 _after_ dist-packages ? 그것은 깨진 설치 IMO입니다.

맞습니다. 사용자 설치는 site(/dist)-패키지보다 먼저 이루어져야 하며, 시스템 스크립트 및 유틸리티는 -I(또는 Python 2의 경우 -E)와 함께 실행되어야 합니다.

그래, 난 동의 :). 생생하게 수정될 수도 있지만 완전히 잘못된 곳에서 일이 오고 있다는 보고가 분명히 있는 것 같습니다.

실험을 위해 시스템 pip를 사용하여 생생한 컴퓨터에 setuptools를 설치했습니다.

>>> import setuptools
>>> setuptools.__path__
['/home/robertc/.local/lib/python2.7/site-packages/setuptools']
>>> import sys
>>> sys.path
['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/home/robertc/.local/lib/python2.7/site-packages', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PILcompat', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7', '/home/robertc/work/mock']

그래서 이것은 제정신입니다. 그러나 혼란스럽게도 이것은 생생한 - 그래서 IDK에서 소개되었습니다. 어느 시점에서 재생기를 파낼 수 있는지 확인하겠습니다 (Ubuntu BTS에 파일링하기 위해)

페이징 @warsaw

사용자 사이트 패키지는 setuptools의 사악한 .pth 파일 에 의해 전역 사이트 패키지 이후로 재정렬될 수 있습니다. 이것들은 setup.py 를 직접 사용하지 않는다는 것을 배울 때까지 반복되는 문제였습니다. 무언가를 설치하려고 하다가 갑자기 다른 모든 종류의 이전 버전을 사용하고 있었습니다. 몇 번 후, 나는 내 시스템을 풀기 위한 공격적인 도구 를 작성했습니다.

적어도 당분간 pip는 명령이 실패하면 사용자에게 --user 를 실행하도록 요청하는 친숙한 메시지를 인쇄해야 한다고 생각합니다. 기본값으로 전환하면 이점이 있지만 더 나은 메시지를 인쇄하는 것은 너무 어렵지 않아야 합니다.

실제로 --user 기본값으로 이동할 때까지 문제에 대한 좋은 "빠른 수정"입니다.

사용자 모드가 /etc/pip.conf에 설정된 경우 --global, --system 또는 --no-user도 필요합니다. 내가 말할 수있는 한 사용자가 이것을 무시하는 쉬운 방법은 없습니다.

문제에 대한 좋은 "빠른 수정"입니다.

늦은 업데이트: #4233이 이 작업을 수행했습니다.

Windows를 사용하지 않는 사람들(특히 신규 이민자)이 좋은 경험을 하고 싶다면 실제로 https://github.com/pyenv/pyenv 로 안내해야 합니다. 특히 ~/.local 가 XDG_DATA_HOME이기 때문에 PEP 370은 오늘날 나에게 그다지 의미가 없습니다.

나는 이 행동이 닥치면 이 행동을 선택하지 않을 유일한 사람이 아니라고 생각합니다. pyenv에 매우 만족하기 때문에 전환이 원활하고 시스템 작동 방식을 변경하고 추가 CLI 플래그를 전달할 필요가 없기를 바랍니다. 물론 pyenv가 Windows에서 얼마나 잘 작동하는지 모르지만 bash 하위 시스템이 도움이 될 수 있습니다...

@jcrben pyenv 는 사람들이 Python을 사용하는 방법(특히 Python 바이너리를 얻는 방법)에 대해 몇 가지 가정을 합니다. 즉, 이러한 가정이 유효한 사람들에게는 매우 잘 작동하지만 기본 권장 사항이 되기에는 충분히 보편적이지 않습니다(이 점에서 conda 와 유사함).

pip 수준의 --user 기본값은 올바르게 구성된 Python 가상 환경 내에서는 영향을 미치지 않으므로 이 변경이 conda 및 pyenv 와 같은 타사 환경 관리자에 미치는 영향 pip 및 기타 도구가 감지할 수 있는 방식으로(즉, virtualenv 보고하는 방식, 또는 표준 라이브러리의 venv 방식).

관련 제안: https://github.com/pypa/pip/issues/1056#issuecomment -218130183.

~ ~/.local 에 직접 설치하는 것을 피하기 위해 사용자가 디렉토리를 사용자 정의할 수 있도록(아마도 env 변수를 통해) 허용하는 것이 고려되었습니까? 나는 아마도 그것들을 ~/.local/pip 또는 무엇인가에 내포하고 싶습니다 - 내가 염려하는 한 Python은 해당 공유 공간의 최상위 수준에 대한 특별한 권한이 없습니다. ~ 9.0.1에서는 ~/.local/lib/python<version> 아래에 항목을 중첩하고 ~/.local/bin 에 실행 파일을 추가하는 것으로 보입니다.

@jcrben Aye, 대상 위치는 실제로 Python의 사용자 사이트 디렉터리이며 시스템 사이트 패키지 디렉터리의 명명 체계를 반영합니다. https://docs.python.org/3/library/site.html#site.USER_SITE

이는 PYTHONUSERBASE 환경 변수를 통해 인터프리터 수준에서 이미 구성할 수 있습니다. https://docs.python.org/3/using/cmdline.html#envvar -PYTHONUSERBASE

관심 있는 사람들을 위해 이 동작을 기본으로 하는 패키지 명령 install , uninstall 및 update 가 있는 https://github.com/ofek/hatch 를 출시했습니다. 시스템 변경을 위해 사용자는 https://github.com/npm/npm 과 유사한 -g/--global 옵션을 사용할 수 있습니다.

PyPI 의 맬웨어 감염 패키지에 대한 최근 문제를 감안할 때, 특히 설정 스크립트가 설치 시 임의의 코드를 실행할 수 있다는 점을 고려하여 sudo pip install ... 의 사용을 억제하기 위해 할 수 있는 일을 하는 것이 pip에 가장 유익하다고 생각합니다. 감염된 패키지를 사용자로 설치하는 것만으로도 충분하지만 루트로 설치하면 훨씬 더 나쁩니다.

사용자 설치를 기본값으로 설정하면 pip 명령 앞에 sudo를 추가하는 사람이 줄어들어 실수로 설치된 맬웨어가 더 적은 작업을 수행할 수 있습니다.

구체적인 다음 단계로 --global 플래그 추가에 대한 별도의 문제를 제기했습니다. https://github.com/pypa/pip/issues/4865

이것은 virtualenv 또는 conda 환경에서 거의 확실히 나쁜 생각입니다. 한 환경이 활성 상태일 때 .local 에 설치된 모든 것이 다른 환경을 쉽게 손상시킬 수 있습니다. 그렇다면 그 경우에는 어떤 생각을 하고 있을까요?

cc @msarahan @kalefranz

이 문제는 활성 가상 환경 내부에는 적용되지 않습니다. 활성 환경이 감지되지 않고 대상 정의 옵션( --prefix , --root 등)이 제공되지 않은 경우에만 적용됩니다. 명령줄에서.

이것은 어떻게 결정되고 있습니까?

@jakirkham https://github.com/ofek/hatch/blob/df2c9d46ee7713a1bc156c361cfd0f78e5935297/hatch/utils.py#L19 -L25

우리는 기본적으로 conda에 의해 설치된 모든 python인 conda 환경 내부의 python에 대해 sys.path 에서 기본적으로 ~/.local 를 비활성화하는 것을 고려했습니다. 그래도 까다롭습니다. 어느 쪽이든 우리는 사용자 그룹의 기대치를 위반하게 될 수 있습니다. https://github.com/conda/conda/issues/7173 에서 토론

pip가 PIP_ 로 시작하는 환경 변수에서 인수를 로드할 수 없었습니까? --user 에서 작동합니까? 전체 변수 이름은 무엇입니까?

PIP_USER 입니다.

문서: https://pip.pypa.io/en/stable/user_guide/#environment -변수

PIP_USER=yes 정확히 말하면 감사합니다! 환경 변수를 사용하면 환경 변수를 한 번만 정의하면 명령이 호출될 때마다 사용되므로 CI 사용이 훨씬 쉽습니다.

분명히 일부 단계는 virtualemv 없이 일반 사용자로 실행되고 일부는 virtualenv 내부에서 실행되는 travis에 대해 정말 추악한 논리를 수행해야 했습니다.

virtualenv 내부는 사이트 패키지(다른 문제를 일으키고 있음)를 사용하지 않으면 사용자가 실패할 가능성이 있습니다.

bash에서 virtualenv를 감지하고 -user 추가를 피해야 했고 그렇지 않으면 실행이 실패합니다.

이것은 추악하고 디버깅에 많은 시간을 낭비하게 만들었습니다. 다른 사람들도 같은 문제에 직면할 것이라고 확신합니다.

가능한 경우 사용자에게 설치하고 시스템으로 대체하는 것과 같이 설치와 관련하여 대체를 활성화하는 옵션이 필요하다고 생각합니다.

pip는 패키지를 설치할 장소를 찾지 못한 경우에만 실패해야 합니다.

이에 대한 움직임이 있습니까?

언급된 것을 보지 못했지만 sudo에서 실행할 때 --user가 전달되면 pip가 불평해야 할 것입니다.

이러한 미해결 문제로 인해 프로그래머는 pip 및 python에서 멀어지고 이와 같은 문제가 적은 다른 패키지 또는 javascript 및 npm과 같은 다른 프로그래밍 언어를 사용하게 됩니다. 파이썬을 사용하려는 새로운 초보자에게는 이러한 추가 필수 옵션이 실망스럽습니다.

--user가 기본값인 이유는 무엇입니까? 명시적으로 지정할 수 없나요? 사용자와 함께 사용할 수 없다고 불평하기 때문에 pip --target을 실행할 수 없습니다. 그것을 피하는 방법에 대한 아이디어가 있습니까?

@dmikov : 기본값이 아닙니다. Debian/Ubuntu 깨진 버전 을 사용하지 않는 한 PIP_USER=0 pip install -t ... 를 사용하여 --user 가 자동으로 설정되는 문제를 해결할 수 있습니다. 또는 더 나은 방법은 공식 버전을 설치하고 사용하는 것입니다.

나는 밤에 --user 옵션이 기본값이 되는 꿈을 꾸었습니다(농담 아님). 내 꿈이 곧 이루어질 가능성이 있습니까?

잘못된 구문이 계속 표시되는 파이 게임 설치에 도움이 필요합니다.

나는 사용했다
python3 -m pip 설치 -U 파이 게임 --사용자
이게 잘못된 건가요?

@flamedro56 : 임의의 문제에 대해 논평하는 대신 새 문제를 열고 Python 버전, pip 버전, 운영 체제, 명령 출력 등의 추가 정보를 제공하세요.

설치 프로그램 reCAPTCHA

새로운 구성 옵션 default=system,user를 갖는 것은 어떻습니까? 아무도 "가상 환경에서도 항상 사용자"를 의미한다고 생각하지 않을 만큼 충분히 명시적입니다. 그것은 정상적인 마이그레이션 경로를 허용합니다.

#4575를 참조하십시오.

Manjaro 가 --user 을 기본값으로 설정하려고 하는 것 같습니다.

이 문제에 대해 업스트림에서 새로운 것이 있습니까?

@Tids : "filesystem-2018.9-3은 기본적으로 $HOME/.local/bin을 $PATH에 추가합니다." Manjaro가 올바르게하고있는 핵심 추가 조각입니다.

Debian은 Python 수준에서 "default to --user"를 사용자 계정 수준에서 "$HOME/.local/bin이 기본적으로 $PATH에 없습니다"와 결합합니다. 이것이 문제를 해결하는 콤보입니다.

#7002에서 전역 site-packages dir을 쓸 수 없고 사용자 site-packages가 활성화된 경우 기본적으로 pip가 사용자 설치를 수행하도록 시도했습니다. 이는 환경을 수정할 수 있는 권한이 있는 한 환경에 설치하려고 할 때 사용자 설치를 수행하는 것을 크게 피해야 합니다.

저는 먼저 아이디어에 대한 토론을 찾고 있습니다. 구현을 검토하는 데 수렁에 빠지지 말고 그 일을 하는 것이 타당한지 생각하지 맙시다.

사용자 설치와 비사용자 설치(pip 자체의)를 혼합하면 문제가 많다는 점은 주목할 가치가 있습니다. 최근 #7209를 한 예로 참조하십시오.

이 문제와 직접적인 관련은 없지만(실제로 사용자를 기본값으로 설정하면 상황이 다소 완화될 수 있음) --user 로의 전환을 기본값으로 처리하는 방법에 대해 신중하게 생각할 필요가 있음을 강조합니다.

(저는 주로 이 주석을 여기에 추가하고 있으므로 어딘가에 기록됩니다. 대부분 pip 문제가 아니라 Python의 USER_SITE 디렉토리가 일반적으로 작동하는 방식의 합병증이며 --user 로 설치하는 사용자가 충분히 이해하지 못합니다.

PATH (명령 찾기용) 및 sys.path (Python 가져오기 찾기용)의 우선 순위가 반대이므로 한 설치의 런처 스크립트가 패키지를 로드하려고 시도하는 것이 문제인 것 같습니다. 다른. 아마도 pip에만 국한된 것은 아닙니다. 스크립트를 설치하는 모든 패키지에 영향을 미칠 수 있습니다.

우리가 그것에 대해 무엇을 할 수 있는지 확실하지 않지만 생각해 볼 가치가 있다는 점에는 동의합니다.

네, 그것이 제가 염두에 두었던 주요 "USER_SITE의 합병증"입니다. IMO, 래퍼 스크립트를 사용하지 않고 python -m pip 만 지원하는 것이 가장 효과적인 솔루션입니다. (저는 래퍼 자체에 반대하지 않지만 우리가 볼 수 있는 문제는 일반적으로 사람들이 실수로 잘못된 래퍼를 실행하는 것이므로 래퍼 스크립트 문제를 수정 하는 것은 일반적으로 pip 문제가 아니라 "사용자 환경의 잘못된 구성 진단 및 수정 " 문제)

pip 래퍼 스크립트를 더 이상 사용하지 않는다는 뜻입니까, 아니면 pip가 설치할 수 있는 것으로 래퍼 스크립트를 사용하지 않는다는 뜻인가요?

나는 확실히 후자에 대해 -1입니다. 명령을 설치하는 기능은 문제가 발생하더라도 매우 유용합니다.

$#$ python -m pip pip 를 비추천하는 것이 더 합리적일 수 있습니다. pip가 실행 중인 Python 환경에 설치될 때 어떤 환경인지 명확히 이해하는 것이 좋습니다. 그러나 그것은 여전히 ​​편의성을 상실하고 사람들에게 익숙한 것에 큰 휴식이 될 것입니다.

나는 특히 pip 자체에 대한 래퍼 스크립트를 의미했습니다. 편의성 상실에 동의하고 어떤 형태로든 유지하는 것에 반대하지 않을 것입니다(#3164는 래퍼를 제공하는 새로운 pip-cli 프로젝트를 제안함). 그러나 핵심은 python -m pip 에 대한 것입니다. 지원 되는 pip 실행 수단입니다.

현재 python (PATH 또는 python -m pip 와 함께 사용되는 항목)이 $#에서 사용하는 pip python 가 아닌 경우 pip 래퍼 스크립트를 호출하면 경고가 표시됩니다. pip ? 이런 식으로 호출하면 python -m pip 에 위임할 수도 있습니까?

유사하게, pipenv는 사용자가 이미 virtualenv에 있으면 경고하고, 그렇다면 경고를 내보낸 후 자신의 virtualenv를 관리하는 대신 해당 virtualenv를 사용합니다.

자, 여기에서 #7002는 이 시점에서 6명의 pip 유지 관리자 중 3명의 승인을 받았습니다.

어쨌든 사용자 설치를 실제로 수행해야 하는 대부분의 경우 기본적으로 비사용자 설치에서 사용자 설치로 pip 전환을 수행합니다. 이 변경을 수행하는 것과 관련하여 두 가지 더 큰 우려 사항이 있습니다. 바로 그 개선 사항을 만드는 릴리스를 만들기 전에 파악해야 한다는 것입니다.

• 기본적으로 사용자 설치로 전환하면 사용자 설치를 명시적으로 옵트아웃하는 메커니즘을 원하십니까? 그렇다면 --no-user 와 어떻게 다를까요? (명시적 옵트아웃으로 --no-user 의 이름을 --global 로 변경하는 데 동의합니다.)
• 우리의 "전환" 전략은 무엇입니까?
  
  
  
  • 이 변경 사항을 어떻게 전달하고 싶습니까?
  
  
  • 사용자에게 이 업그레이드를 할 때 주의하라고 말하시겠습니까?
  
  
  • 이 변경 사항이 구현되고 릴리스될 때 사용자가 어떤 종류의 문제를 제기할 것으로 예상합니까?
  
  

환경 내부에 있다면 --global 의 이름이 잘못되었다고 말하고 싶습니다. flit install 의 경우 --user 의 반대는 --env 입니다. "시스템 Python 환경"을 느슨하게 포함하려고 했지만 그것도 완전히 명확하지 않은 것 같습니다. 아마도 --no-user 가 여전히 최선의 선택일 것입니다. --user 의 반대입니다.

현재 기본값은 사실상 user = False 이므로 --no-user (또는 동등한 환경 변수 또는 구성 항목)이 기존 동작을 되돌려야 한다고 생각합니다.

내가 생각해낸 변경 사항이 혼란스러울 수 있는 유일한 시나리오는 환경(예: conda가 활성화된 사용자 사이트)에 설치할 수 있는 권한이 있다고 생각하지만 실제로는 그렇지 않은 경우입니다. 사용자 설치에 대한 로그 메시지가 있더라도. 개선할 좋은 방법이 생각나지 않았습니다.

쓰기 가능성 감지가 잘못될 수도 있습니다. 가양성은 기존 동작을 제공합니다(일반 설치를 시도하고 실패). 거짓 부정은 정상적인 설치를 수행할 수 있을 때 사용자 설치를 수행합니다.

기본적으로 비 사용자 설치에서 사용자 설치로 pip 전환을 수행합니다.

예를 들어 Windows에서는 그렇지 않습니다. 여기서 (기본적으로) Python 설치는 사용자별 설치이고 사이트 패키지 는 기본적으로 쓰기 가능합니다. 이것은 내가 #7002에 대해 일반적으로 선호하는 것입니다. 왜냐하면 이 문제(#1668)가 열린 이후의 경험은 pip와 같은 패키지가 둘 다 사이트 패키지에 설치된 "혼합" 환경에서 엉망이 되기가 너무 쉽다는 것 입니다. 및 사용자 사이트. 그래서 지금은 가능하면 시스템 설치를 하고, 사이트 패키지를 작성할 수 없는 Linux 시스템 관리 Python과 같은 경우에만 사용자 설치를 수행하는 것을 선호합니다.

라고 한:

1. #7002는 시스템 설치가 실패할 경우에만 사용자 설치를 의미하므로 --no-user 옵션은 의미가 없는 것 같습니다.
2. 전환과 관련하여 우리가 의사 소통해야한다고 생각하는 가장 큰 것은 사람들이 다중 설치에 대해 매우 조심해야한다는 것입니다. 이는 pip의 해결 방법이 아니라 사용자 이해와 교육에 의해서만 처리 될 수있는 것입니다. 그것은 기본적으로 핵심 파이썬 문제입니다. 사이트가 있고 사용자가 패키지를 설치하고 사용자가 사이트를 섀도잉하고 있을 때 보고하도록 pip check 를 확장할 수 있습니다. 제 생각에는...

--no-user 옵션에 대한 의미가 없는 것 같습니다.

분명히 이것은 이미 존재하지만 종종 유용하지는 않을 것입니다. 구성 파일에 user=true 가 있는 경우 --no-user 가 이를 재정의해야 합니다.

분명히 이것은 이미 존재합니다.

죄송합니다. 더 명확했어야 했습니다. 적어도 @pradyunsg 가 의미한다고 가정한다는 의미에서 "기본적으로 사용자 설치를 명시적으로 옵트아웃하는 메커니즘"을 갖는 것은 의미가 없습니다. 내가 말했듯이 "기본적으로 사용자 설치로 전환"과 동일 하지 않습니다 .

사실, 나는 그것이 더 명확한지 확신하지 못합니다 ;-) 아마도 내가 말하고 싶은 것은 "현재 우리가 가진 것보다 더 많은 옵션이 필요하지 않습니다"...

흠... @pfmoore #7002 이후에 이 문제가 해결되었다고 하려면 무엇이 필요한가요?

추신: 그 이전 댓글을 급하게 작성했는데 실수로 게시되었습니다. 총알은 괜찮습니다. 나는 그것이 게시되기 전에 그 단락의 초안을 작성하고 있었습니다. 혼란을 드려 죄송합니다.

@pradyunsg 이제 절대적으로 필요한 경우가 아니면 --user 를 기본값으로 사용하는 것이 좋은 생각이라고 생각하는 경향이 훨씬 줄어들었다는 점을 감안할 때(사례 #7002 주소) 이 문제를 다음과 같이 포기할 수 있다고 말하고 싶습니다. #7002가 완료되었으므로 더 이상 좋은 생각이 아닙니다.

2개의 글머리 기호를 #7002를 완전한 것으로 계산해야 할 수 있는 것으로 취하면 위 의 내 의견이 이를 다룹니다.

여기에서 릴리스 정보를 따랐습니다.
https://pip.pypa.io/en/stable/news/#id3
"기본 사이트 패키지 디렉토리가 쓰기 불가능하고 사용자 사이트 패키지가 활성화된 경우 사용자 설치(--user가 전달된 것처럼)를 수행하는 것이 기본값입니다. (#1668)"

내 빌드는 이제 실패합니다.

ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

이것은 내 pip 명령에서 --user를 제거하여 해결된 것 같습니다.

이것이 예상된 행동이었습니까? 릴리스 노트는 이것을 반영하지 않는 것 같습니다.

이제 pip 20.0.1에서 실패하는 스크립트에 대한 링크(--user를 제거하면 하드 오류가 수정됨)
https://github.com/lfit/releng-global-jjb/blob/master/shell/python-tools-install.sh

사용자 사이트 패키지를 해당 환경에서 가져올 수 없는 것이 맞다면 이는 예상되는 동작이지만 이 PR과 직교합니다. 이 검사는 몇 년 전에 도입되었지만(#567) 최근까지(#7155) venv로 인해 손상된 것 같습니다. 이에 대한 릴리스 노트가 있습니다.

venv(PEP 405)로 생성된 가상 환경에서 시스템 사이트 패키지를 올바르게 처리합니다.

아 네, 댓글 감사합니다. 나는 이것을 알아 냈습니다 ...
내 스크립트가 .local/bin/을 채우고 있었습니다.
내가 달렸을 때

python3 -m venv ~/.local

그런 다음 우분투 로그인 셸에서(#!/bin/bash -l) .local/bin이 경로에 추가됩니다(그래서 python3을 호출하면 이제 .local/bin/python3 실행 파일이 호출됨).
python3 -m venv ~/.local을 실행할 필요가 없었습니다.
또는 로그인 셸에서 내 스크립트를 호출하고 이러한 문제 중 하나 또는 둘 모두를 제거하면 문제가 해결됩니다.

#fresh ubuntu docker
root<strong i="13">@7d8107816f64</strong>:/# python3 -m pip install  --user --upgrade pip
Successfully installed pip-20.0.1
root<strong i="14">@7d8107816f64</strong>:/# python3 -m pip --version
pip 20.0.1 from /root/.local/lib/python3.6/site-packages/pip (python 3.6)
root<strong i="15">@7d8107816f64</strong>:/# ls root/.local/bin/pip
pip     pip3    pip3.6
#Now we populate ~/.local/bin/
root<strong i="16">@7d8107816f64</strong>:/# python3 -m venv ~/.local
root<strong i="17">@7d8107816f64</strong>:/# ls root/.local/bin/
activate          activate.fish     easy_install-3.6  pip3              python
activate.csh      easy_install      pip               pip3.6            python3
root<strong i="18">@7d8107816f64</strong>:/# ./root/.local/bin/python --version
Python 3.6.9
root<strong i="19">@7d8107816f64</strong>:/# ./root/.local/bin/python -m pip install  --user --upgrade pip
ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

따라서 실행 가능한 .local/bin/python을 실행하면 --user를 사용하여 pip install을 할 수 없습니다.

오, 당신이 python3 -m venv ~/.local 하고 있다는 것을 놓쳤습니다. ~/.local 는 --user 설치(Linux에서)의 접두어이기 때문에 pip와 같은 도구를 혼동할 수 있습니다. venvs와 --user 는 시스템 전체를 변경하지 않고 패키지를 설치할 수 있는 두 가지 _다른_ 방법입니다. 둘 중 하나를 사용해야 합니다. ~/.local 에서 가상 환경을 만들면 둘의 이상한 하이브리드가 됩니다.

새로운 동작은 아마도 많은 사람들에게 편리할 것 같지만 '사용자' 설치는 웹 개발자로서 저에게 약간의 슬픔을 안겨주었습니다. 저는 종종 프로덕션 머신에 배포될 가상 환경을 준비해야 하고, 내 사용자 라이브러리에 패키지가 설치된 경우, 기본적으로 pip 는 내가 준비하고 있는 virtualenv에 설치하는 것을 거부하고 여전히 성공으로 종료됩니다 . 패키지를 설치하지 않기로 결정했다는 알림은 virtualenv를 준비하는 데 사용하는 스크립트의 출력 30~40페이지 안에 묻혀 있습니다. 최종 결과는 virtualenv가 배포되면 내 홈 디렉토리의 패키지를 더 이상 사용할 수 없으므로 프로덕션 웹 앱에서 일부 임의 패키지가 누락되어 죽은 것입니다.

제 사용 사례가 일반적인 사례가 아니라는 점을 기꺼이 인정합니다. 그래서 아마도 이것은 일반적인 사용성 관점에서 여전히 좋은 아이디어였을 것입니다.

비슷한 문제를 겪은 다른 사람들을 위해 몇 가지 방법이 있습니다.

• 스크립트 등의 모든 pip install 명령줄에 --force-reinstall 추가
• ~/.local/lib/python* ~/.pip/pip.conf 를 편집하여 global 섹션에 user = no $를 추가합니다.

[global]
user = no

• ~/.local/lib 를 디렉토리가 아닌 파일로 변경하는 것과 같이 더 과감한 작업을 수행하십시오.

항상 그렇듯이, 사랑하는 포장 관리자 여러분, 모든 일에 감사드립니다. 누군가의 물건을 손상시키지 않고 무엇이든 바꾸는 것은 사실상 불가능하며 어쨌든 위조한다는 사실은 실제로 훌륭합니다. 왜냐하면 그것이 우리를 발전시킬 수 있기 때문입니다.

아, 사용자 설치는 동일한 사용자 계정으로 많은 다른 항목이 실행되지만 사람들은 여전히 ​​빌드가 서로 격리되기를 기대하는 지속적인 통합 환경에서 큰 문제를 일으킬 수 있습니다. 우리는 ~/.local 를 읽기 전용으로 만들어 이 문제를 해결했지만 위의 솔루션도 작동할 것입니다.

기본 옵션으로 virtualenv를 만들면 격리됩니다. 사용자 또는 시스템 사이트 패키지를 볼 수 없으므로 pip는 해당 환경에 설치된 패키지에서만 작동해야 합니다. 이것은 정확히 당신이 설명하는 문제의 종류 때문에 몇 년 전에 기본값이 되었습니다.

--system-site-packages 옵션을 사용하여 virtualenvs를 생성하는 경우(또는 이것이 기본값인 매우 오래된 버전의 virtualenv), 시스템 전체와 가정에서 설치했을 패키지의 오버레이 역할을 합니다. 예배 규칙서. 시스템 패키지는 표시하지만 사용자 패키지는 표시하지 않으려면 -s 옵션 또는 PYTHONNOUSERSITE 환경 변수 를 사용하여 Python을 실행할 수 있습니다.

오! 정말 죄송합니다. 당신이 완전히 옳았습니다. 우리 조직의 이상한 시스템 사이트 패키지 정책이 다시 적용됩니다. 몇 가지 솔루션을 지적해 주셔서 감사합니다.

문제 없어요. 시스템 사이트 패키지는 몇 년 전 numpy와 같은 작업을 위해 시스템 패키지 관리자에 자주 의존했을 때 더 일반적이었습니다. 따라서 해당 정책을 다시 살펴볼 가치가 있습니다. 그러나 오늘날에도 여전히 그것을 사용해야 하는 합리적인 이유가 있습니다.

https://github.com/pypa/pip/issues/1668#issuecomment -544569965에 따라 종료합니다.

@takluyver 감사합니다! ^>^

@takluyver 오랫동안 저를 괴롭혔던 문제를 해결해주셔서 감사합니다
그러나 권한이 없는 사용자와 함께 패키지를 설치할 때 pip 20.0.2가 포함된 Windows 10 python 3.8.2가 여전히 실패하는 것으로 나타났습니다.

ERROR: Exception:
Traceback (most recent call last):
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\cli\base_command.py", line 186, in _main
    status = self.run(options, args)
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\commands\install.py", line 253, in run
    options.use_user_site = decide_user_install(
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\commands\install.py", line 604, in decide_user_install
    if site_packages_writable(root=root_path, isolated=isolated_mode):
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\commands\install.py", line 548, in site_packages_writable
    return all(
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\commands\install.py", line 549, in <genexpr>
    test_writable_dir(d) for d in set(get_lib_location_guesses(**kwargs))
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\utils\filesystem.py", line 140, in test_writable_dir
    return _test_writable_dir_win(path)
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\utils\filesystem.py", line 153, in _test_writable_dir_win
    fd = os.open(file, os.O_RDWR | os.O_CREAT | os.O_EXCL)
PermissionError: [Errno 13] Permission denied: 'c:\\program files (x86)\\python38-32\\Lib\\site-packages\\accesstest_deleteme_fishfingers_custard_m59lch'

나는 이것이 OSError 의 errno 가 errno.EACCES 이지만 errno.EPERM 로 인해 발생할 수 있다고 생각했습니다.

@catPill 제대로 추적할 수 있도록 새 문제를 열어 주세요. 내가 Windows에서 뭔가를 놓쳤다는 것은 완전히 그럴듯합니다.