최근 배포판에서 pip install 을 하면 설치가 시작되기 전에 막힌다.
error: externally-managed-environment
x This environment is externally managed
+-> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to install.
PEP 668 이 도입한 동작이다. 배포판이 제공하는 파이썬은 OS 도구들이 함께 쓰는 런타임이다. 여기에 pip 로 패키지를 덮어쓰면 의존성이 어긋나면서 패키지 관리자로 설치한 도구들이 깨진다. 실제로 dnf 나 apt 자체가 파이썬으로 만들어져 있어 복구가 까다로워진다.
배포판은 /usr/lib/python3.x/EXTERNALLY-MANAGED 라는 표식 파일로 이 상태를 알린다. 오류는 고장이 아니라 의도된 보호 장치다.
작업용 환경을 따로 만든다. 이것이 표준 대응이고, 다른 방법을 찾기 전에 이것으로 해결되는지부터 본다.
python3 -m venv ~/venvs/work
source ~/venvs/work/bin/activate
pip install --upgrade pip
pip install azure-identity azure-storage-file-datalake
venv 모듈이 없다는 오류가 나면 배포판 패키지로 먼저 넣는다.
dnf install -y python3-pip python3-devel # RHEL 계열
apt install -y python3-venv python3-pip # Debian 계열
명령행 도구 성격의 패키지라면 pipx 를 쓰면 도구마다 격리된 환경이 자동으로 만들어진다.
pipx install awscli
python3-requests 처럼 배포판이 패키지로 제공하는 것이라면 그쪽이 낫다. 보안 업데이트를 OS 와 함께 받는다.
dnf search python3- | grep -i <이름>
dnf install -y python3-<이름>
자동화 스크립트가 전역 설치를 전제로 짜여 있어 당장 바꿀 수 없을 때가 있다. 이때도 표식 파일을 지우지는 않는다. 명령 단위로 예외를 준다.
pip install --break-system-packages <패키지>
또는 사용자 홈에만 설치한다. 시스템 경로를 건드리지 않으므로 --break-system-packages 보다 안전하다.
pip install --user <패키지>
--user 로 설치한 실행 파일은 ~/.local/bin 에 들어간다. WARNING: The script ... is installed in '/home/<user>/.local/bin' which is not on PATH 가 나오면 그 경로를 PATH 에 넣는다.
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
EXTERNALLY-MANAGED 파일을 지우는 것은 하지 않는다. 경고만 사라지고 원래 막으려던 사고는 그대로 일어난다.