pip install -e의 의미, 아직도 패키지 그렇게 편집하세요?

🤔 Problem

본 포스팅에 들어가기 전, 유의사항을 알려드립니다. 이번 포스팅의 내용은 원격 저장소와는 아무런 관련이 없습니다. 조금 헷갈릴 수 있기 때문에 미리 적어둡니다. 이 글에서 말하는 패키지(라이브러리)는 '깃에서 클론한 레포지토리', '자체 개발 패키지' 등 로컬 상에 존재하는 패키지(폴더)를 의미합니다. '깃의 원격 저장소', 'PyPI'와 같은 원격저장소에 위치한 (아직 로컬에 설치하지 않은) 패키지와는 거리가 먼 내용입니다.

 

오픈소스를 핸들링하다 보면, 레포지토리를 clone하고, 해당 레포지토리로 이동하여 requirements.txt에 따라 설치하면서 아래와 같은 명령어를 자주 볼 수 있었습니다.

pip install -e .

option을 확인해 보면, '해당 경로에 위치한 패키지(라이브러리)를 editable하게 설치할 것이다.'라는 의미로 해석됩니다.

하지만, 의아하게도 그건 -e 옵션 없이도 가능합니다. 해당 패키지가 설치된 site-packages 경로로 가서 코드를 주어진 작업에 맞게 수정하면 이게 editable 아닐까요?

 

아니면, 그 패키지 자체를 사용하려는 프로젝트 폴더에 패키지를 넣고 사용할 수도 있죠. (폴더가 많이 지저분하겠지만😂)

 

하지만, 위에서 말한 것처럼 패키지를 편집을 한다는 것은 해당 패키지를 내 프로젝트에 fit하게 변경해 주기 위해서 패키지를 편집하는 것입니다.

패키지라는 것의 본질적인 목적은 여러 프로젝트에서 자주 사용되는 기능들을 구현해 모아둔 것입니다. (ex: numpy, matplotlib 등)

즉, 패키지에서 개발되거나, 편집되는 코드들의 목적은 조금 더 범용적인 사용을 하기 위함인 것입니다. 이에 따라 주로 패키지 편집이라는 것은 특정 프로젝트에 겨냥한 편집을 하기보다 패키지 자체의 더 범용적인 기능들을 생각해서 편집이 들어가게 됩니다. 그래서, 패키지를 업데이트 혹은 편집을 한다는 것은 프로젝트를 넘어 더 큰 그림을 봐야 합니다.

 

패키지를 편집한다는 것의 목적을 알고 있는 상태에서 이런 상황을 가정해 봅시다.

내가 개발한 패키지가 내가 만들고 있는 어떤 프로젝트에서 pip install <package 경로>을 해서 사용하고 있다고 했을 때, 프로젝트를 하다 보니 패키지에 'A라는 기능이 추가되었으면 좋겠다'는 생각이 듭니다. 그러면, site-packages에 있는 패키지 코드를 편집하실 건가요? 좋습니다. 하지만, pip install <package 경로>가 어떻게 작동했는지 안다면 생각이 달라질 겁니다.

pip install <my_package path>

위 그림은 pip install <package 경로>를 실행했을 때, 패키지가 가상 환경에 생기는 방법입니다. 그림처럼 가상 환경에 패키지를 설치하면, 패키지의 복사본이 생깁니다. 패키지 자체의 업데이트를 해주기 위해 편집을 하고자 했던 건데 복사본 코드를 편집한다고 해서 달라지는 게 있나요? 물론, 프로젝트 내에서 사용하게 되는 패키지는 업데이트된 기능들을 사용할 수 있겠지만, 이것은 본질적인 목적에 어긋납니다. 패키지 자체에 대한 업데이트를 하고 싶었으니까요.

 

그러면, 원래의 패키지(그림에서 주황색 박스)의 코드를 수정해 줘야겠네요. 프로젝트 가상 환경에 있는 패키지 복사본은 지워주고 업데이트된 패키지를 설치해야 합니다. 다시 pip install <package 경로>를 하면 됩니다.

 

또 패키지의 업데이트가 필요하다면요? 프로젝트도 하면서 패키지를 자주 업데이트 시킬 수도 있는 상황이라면 번거롭지 않을까요? 이런 상황을 고려하여 패키지를 프로젝트 가상 환경에 설치하는 방법으로 -e | --editable이라는 옵션이 등장하게 됩니다. 

---

😀 Solution

-e | --editable이라는 옵션은 프로젝트 가상 환경에 패키지를 설치할 때, site-packages로 패키지의 복사본을 가져오는 것이 아니라 해당 패키지의 심볼릭 링크를 생성시킵니다.

 

심볼릭 링크란 파일 시스템에서 특정 파일 혹은 디렉토리를 가리키는 특별한 종류의 파일입니다. 즉, 해당 옵션으로 패키지를 가상 환경에 설치하면 패키지를 설치하는 것이 아니라 패키지의 위치를 가리키는 파일을 설치하는 것과 같습니다. 아래 그림처럼 패키지에 접근을 할 수 있게 되는 것인데요.

pip install -e <my_package path>

그래서, 프로젝트 가상 환경에서 sys.path(패키지 위치를 탐색하는 경로)를 출력해 보면 패키지가 로컬에서 위치한 경로까지 담고 있습니다. 

 

결론적으로, editable 옵션을 통해서 편집할 패키지를 번거롭게 여러 번 설치해야 하는 상황을 없애거나, 패키지 자체에 대한 작업을 독립적인 관점으로 바라볼 수 있다는 것입니다.

---

😀 Experiment

이러한 옵션의 역할을 수행하는지 확인하기 위해서 Hugging Face의 transformers 라이브러리를 git clone 하여, r각 가상 환경에 따라 옵션 유무를 정하여 설치하고, 내부에 임의의 스크립트(doby_hello.py, doby_hi.py)를 만들어 확인한 결과, -e 옵션을 사용해야 패키지를 독립적으로 편집해도 심볼릭 링크에 의해서 패키지 업데이트가 추적이 가능합니다.

pip install 로 하고 라이브러리에 doby_hello.py 추가했을 때 (라이브러리 복사본)

pip install -e 로 하고 라이브러리에 doby_hi.py 추가했을 때 (라이브러리 심볼릭 링크)

---

😀 Conclusion

이번 글은 다소 접근이 어려울 수도 있을 거라 생각이 듭니다. 일반적으로 패키지를 가상 환경에 설치할 때를 생각하면, 원격에 있는 패키지를 프로젝트 가상 환경에서 설치하는 상황은 많지만 로컬에 있는 패키지를 프로젝트 가상 환경에 설치하는 상황은 잘 없기 때문인데요.

 

왜냐하면, 깃허브에서 클론한 레포지토리도 대부분 패키지로 사용하지 않고, 클론한 레포지토리 자체 내부에서 작업하는 경우가 많기 때문이라 생각합니다. 

 

그래서, 실질적으로 -e | --editable이라는 옵션을 사용할 일은 잘 없겠다만, 자주 등장하는 옵션이라 한 번쯤 정리가 필요했습니다.

 

사실 이 기능은 옵션 자체가 깃허브에서 클론한 레포지토리를 패키지처럼 다루는 사람이거나 자체적으로 패키지(라이브러리)를 개발하고 있는 사람이 아니라면, 이 옵션이 필요할까?를 많이 생각하게 됩니다. (찐 개발자 분들이 많이 쓰지 않을까)

 

또한, 본 글에서는 다루지 않지만, 해당 옵션의 대상이 되는 패키지에는 setup.py나 pyproject.toml같은 파일이 필요한데 이건 나중에 또 한 번 필요해진다면 다루어보도록 하겠습니다.