[Python] externally-managed 오류 처리

 

문제 발생

사용하고 있는 conda 환경에서 pip로 패키지를 설치하려는데 다음과 같은 오류가 발생했습니다. 가장 자주 사용하던 환경이라 뭔가 많이 낯설게 느껴집니다. 뭐지?

 

(cu124) sol@solOffice:~$ pip install transformers
error: externally-managed-environment

× 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.
    
    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.
    
    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.
    
    See /usr/share/doc/python3.12/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

 

 

원인 파악

에러 문구를 가지고 검색해 보니 Python의 PEP 668 표준에 의해 시스템 패키지 환경을 보호하기 위해 2021년 5월 이후 채택되었다고 합니다. OS 패키지 관리자와 PIP와 같은 Python 패키지 관리도구간의 충돌이 발생하는 것을 방지하기 위해 시스템 것을 보호하는 조치를 취하게 된 것입니다. 

 

PEP 668 – Marking Python base environments as “externally managed” | peps.python.org

 

하긴... 예전에는 여럿을 혼재해서 사용하는 경우가 많아서, 'which python'을 이용해 지금 내가 작동시키고 있는 python이 어느 path에서 있는 것인지를 확인해야 하는 상황도 있었습니다. 그러다가 Anaconda나 venv와 같은 가상환경 제공 솔루션이 나오면서 이제는 대부분 가상환경 하에서 작업하게 되었죠.

 

 

일반적인 해결방법

 

1.가상환경 사용

 

Anaconda나 venv와 같은 도구를 사용해서 가상환경을 만들어 사용하는 방법을 권장합니다. 그러면 가상환경 내에서는 전용 python, pip를 사용하게 되므로 OS의 것을 건드릴 필요가 없기 때문입니다. 

 

 

2.'--break-system-packages' 옵션 사용 또는 EXTERNALLY-MANAGED 파일 삭제

 

아래 파일이 있다는 것은 외부 관리가 되고 있다는 것을 명시적으로 알 수 있게 한 것입니다. 그래서 이를 삭제해 버리면 그걸 건너뛰도록 하는 효과를 가지게 됩니다. 

 

 

$ sudo rm /usr/lib/python3.12/EXTERNALLY-MANAGED

 

이렇게 하는 것 대신 설치 시 무시하도록 매개변수를 전달할 수도 있습니다. 

$ pip install --break-system-packages transformers

 

하지만, 위의 방식은 둘 다 시스템 안정성을 깨뜨리기 때문에 가능하면 하지 않는 것이 좋습니다. 

 

 

그럼 내 경우 해결은 어떻게?

 

제 경우, 2번 방식은 안정성을 고려해서 패스!, 1번 방식에 대해서는 내가 이미 가상환경을 사용하고 있는데? 였습니다.  그런데... 간혹... 무슨 이유에서인지(대부분 해놓구선 기억을 못하는 케이스~) 가상 환경 내에서도 OS의 기본 python을 사용하는 경우가 생길 수 있습니다. 바로 제 경우가 그랬습니다. 

 

anaconda 가상환경 상에서 원래대로라면 다음과 같이 해당 가상환경 상의 python, pip가 나오는 것이 일반적입니다.

(yolov10) sol@solOffice:~$ which python
/home/sol/anaconda3/envs/yolov10/bin/python
(yolov10) sol@solOffice:~$ which pip
/home/sol/anaconda3/envs/yolov10/bin/pip

 

그런데 이상하게도 제 cu124 환경에서는 이렇게 나오고 있습니다. -_-;

(cu124) sol@solOffice:~$ which python
/home/sol/anaconda3/bin/python
(cu124) sol@solOffice:~$ which pip
/usr/bin/pip

 

아하... PATH 호출하는 순서에 뭔가 개입이 되었구나 싶었습니다. 그래서 .bashrc 파일을 확인해 봤습니다. 

cu124(){
        export CUDA_VER=12.4 #cuDnn 9.2
        export TRT_VER=8.5.1.7
        setPath
}
...
cu124
export PATH=/usr/bin:$PATH

 

역시 cu124 호출 후 시스템 PATH 가 먼저 걸리도록 추가되어 있네요. 기억나진 않지만 뭔가 필요에 의해 넣었던 것 같은데 전혀~ 기억이 나지 않습니다. 일단은 필요없는 것 같으니... 삭제토록 합니다. 

 

시행착오

export 부분을 삭제하고 터미널을 다시 열어 실행해 봅니다. 

(cu124) sol@solOffice:~$ which python
/home/sol/anaconda3/bin/python
(cu124) sol@solOffice:~$ which pip
/home/sol/anaconda3/bin/pip

 

이번에는 anaconda3 공통의 python, pip를 사용하는 걸로 나옵니다. 어, 그래도 내 가상환경 상의 것이 아니네.. 그래서 다시 확인해 봅니다. 원인은 conda activate 이후에 path 설정하는 함수가 호출되어 순서가 뒤바뀌는 현상이 또 있었던 겁니다. 그래서, 최종으로는 'cu124' (환경설정 용 script) -> 'conda activate cu124'(conda 가상환경 로딩)  이렇게 순서를 다시 변경했습니다. 

(cu124) sol@solOffice:~$ conda activate cu124
(cu124) sol@solOffice:~$ which python
/home/sol/anaconda3/envs/cu124/bin/python

 

 

휴... 이젠 정상적으로 나오네요... 간단한 사항이었지만, PEP668 같은 몰랐던 사항도 알게 되었고, 추가로 시행착오를 거치며 '바보 백신'을 한방 맞고 갑니다.