기술 · 실용 가이드
Python의 ‘externally-managed-environment’? 덮어쓰기 전에 인터프리터부터 확인하세요
pip이 가리키는 Python을 증명하고 라이브러리·CLI·OS 구성 요소를 구분한 뒤 결과 경로를 확인하고 --break-system-packages를 판단하세요.
‘externally-managed-environment’는 권한 부족이 아닙니다. pip이 선택한 Python에 EXTERNALLY-MANAGED 표시가 있어 배포자가 기본 환경을 외부 패키지 관리자가 소유한다고 선언한 것입니다.
표시 삭제나 --break-system-packages부터 하지 말고 Python·pip, 설치 목적, 업데이트 책임자를 확인하세요.
실패와 인터프리터를 고정
전체 오류와 원래 명령을 저장하고 python·pip 계열 경로와 버전, sys.executable, sys.prefix, sys.base_prefix를 기록하세요. 증거 수집에 sudo를 쓰지 마세요.
같은 Python으로 python -m pip --version을 실행하세요. 설치가 다르면 PATH, alias, 활성 환경, 호출 도구부터 고치세요.
표시를 소유권 증거로 읽기
규격은 가상 환경 밖이면서 표준 라이브러리에 표시가 있을 때만 기본 환경을 거부합니다. 이는 유지보수 선언이지 모든 설치 방식 금지가 아닙니다.
오류와 배포판 공식 문서를 읽으세요. Debian은 앱에 pipx, 라이브러리에 venv를 권하지만 다른 플랫폼 경로는 다를 수 있습니다.
설치 대상 종류로 경로 선택
프로젝트 라이브러리는 .venv를 만들고 그 python -m pip을 쓰세요. 명시적 인터프리터는 활성화만 믿는 것보다 대상을 증명합니다.
CLI는 pipx, OS·에이전트·관리 호스트 구성 요소는 배포판 패키지나 플랫폼 소유자의 배포 경로를 우선하세요.
덮어쓰기를 예외이자 되돌릴 수 있게
이미지나 인터프리터 수명 주기를 통제하고 의존성을 확인했으며 재빌드할 수 있을 때만 --break-system-packages를 검토하고 명령과 대상을 기록하세요.
한 번의 성공을 위해 표시 삭제, 배포판 pip 교체, 영구 전역 우회를 하지 마세요. 컨테이너는 명시적 venv나 전용 이미지를 쓰세요.
경로, import, 원래 결과 검증
대상 Python으로 __file__ 또는 메타데이터 위치를 출력하고 CLI는 command -v를 확인하세요. 결과는 의도한 venv나 pipx 안이어야 합니다.
같은 사용자로 원래 명령을 재실행하고 모든 경로를 기록하세요. 계속 실패하면 되돌리고 버전, PATH, 호출 도구를 진단하며 범위를 넓히지 마세요.
