파이썬 모듈 설치 (레거시 버전)

저자

Greg Ward

더 보기

파이썬 모듈 설치하기

최신 모듈 설치 설명서. 일반적인 파이썬 사용이라면, 거의 확실하게 이 설명서를 원할 것입니다.

참고

이 문서는 https://setuptools.readthedocs.io/en/latest/setuptools.html 의 setuptools 설명서가 현재 여기에 포함된 모든 관련 정보를 독립적으로 다루기 전까지만 보존됩니다.

참고

이 지침서에서는 이 파이썬 버전의 일부로 제공되는 확장을 빌드하고 배포하기 위한 기본 도구만 다룹니다. 제삼자 도구는 사용하기 쉽고 더 안전한 대안을 제공합니다. 자세한 정보는 파이썬 패키징 사용자 지침서의 quick recommendations section을 참조하십시오.

소개

파이썬 2.0에서, distutils API가 처음으로 표준 라이브러리에 추가되었습니다. 이는 리눅스 배포 관리자에게 파이썬 프로젝트를 리눅스 배포 패키지로 변환하는 표준 방법을 제공하고, 시스템 관리자에게는 대상 시스템에 직접 설치하는 표준 방법을 제공했습니다.

파이썬 2.0이 출시된 이후 수년 동안, 빌드 시스템과 패키지 설치 프로그램을 언어 런타임 배포 주기에 밀접하게 연결하는 것은 문제가 되는 것으로 밝혀졌으며, 이제 프로젝트는 distutils를 직접 사용하기보다, pip 패키지 설치 프로그램과 setuptools 빌드 시스템을 사용하도록 권장합니다.

자세한 내용은 파이썬 모듈 설치하기와 파이썬 모듈 배포하기를 참조하십시오.

이 레거시 설명서는 setuptools 설명서가 필요한 모든 것을 다루고 있다고 확신할 때까지만 유지됩니다.

Distutils 기반 소스 배포

모듈 소스 배포판을 다운로드하면, 표준 방식으로, 즉 Distutils를 사용하여 패키징되고 배포되었는지 매우 빠르게 알 수 있습니다. 첫째, 배포판의 이름과 버전 번호는 다운로드 한 아카이브의 이름(예를 들어 foo-1.0.tar.gz나 widget-0.9.7.zip)에 눈에 띄게 표시됩니다. 다음으로, 아카이브는 비슷한 이름의 디렉터리에 압축 해제됩니다: foo-1.0이나 widget-0.9.7. 또한, 배포판에는 설정 스크립트 setup.py와 README.txt 또는 어쩌면 단순히 README 라는 파일이 포함됩니다. 이 파일은 모듈 배포판을 빌드하고 설치하는 것이 터미널에서 하나의 명령을 실행하는 간단한 문제임을 설명해야 합니다:

python setup.py install

윈도우의 경우, 이 명령은 명령 프롬프트 창(Start ‣ Accessories)에서 실행해야 합니다:

setup.py install

이 모든 것이 참이면, 방금 다운로드 한 모듈을 빌드하고 설치하는 방법을 이미 알고 있는 것입니다: 위의 명령을 실행하십시오. 비표준 방식으로 설치하거나 빌드 프로세스를 사용자 정의해야 하는 경우가 아니라면, 이 설명서가 실제로 필요하지는 않습니다. 또는, 위의 명령은 이 설명서에서 벗어나는 데 필요한 모든 것입니다.

표준 빌드와 설치

섹션 Distutils 기반 소스 배포에 설명된 대로, Distutils를 사용하여 모듈 배포를 빌드하고 설치하는 것은 일반적으로 터미널에서 실행하는 하나의 간단한 명령입니다:

python setup.py install

플랫폼 변형

항상 배포 루트 디렉터리, 즉 모듈 소스 배포가 압축 해제된 최상위 서브 디렉터리에서 setup 명령을 실행해야 합니다. 예를 들어, 모듈 소스 배포 foo-1.0.tar.gz를 유닉스 시스템에 방금 다운로드했다면, 일반적인 작업은 다음과 같습니다:

gunzip -c foo-1.0.tar.gz | tar xf -    # unpacks into directory foo-1.0
cd foo-1.0
python setup.py install

윈도우에서는, 아마도 foo-1.0.zip을 다운로드할 것입니다. 아카이브 파일을 C:\Temp로 다운로드했으면, C:\Temp\foo-1.0으로 압축이 풀립니다; 그래픽 사용자 인터페이스가 있는 아카이브 조작기(가령 WinZip)나 명령 줄 도구(가령 unzip이나 pkunzip)를 사용하여 아카이브의 압축을 풀 수 있습니다. 그런 다음 명령 프롬프트 창을 열고 다음을 실행하십시오:

cd c:\Temp\foo-1.0
python setup.py install

작업 분할하기

setup.py install을 실행하면 한 번의 실행으로 모든 모듈을 빌드하고 설치합니다. 점진적으로 작업하는 것을 선호하면—특히 빌드 프로세스를 사용자 정의하거나, 문제가 발생하면 특히 유용합니다—설정 스크립트를 사용하여 한 번에 한 가지 작업을 수행할 수 있습니다. 이는 빌드와 설치를 다른 사용자가 수행할 때 특히 유용합니다—예를 들어, 모듈 배포를 빌드하고 설치를 위해 시스템 관리자에게 넘겨주고 싶을 수 있습니다 (또는 슈퍼 유저 권한으로, 직접 수행합니다).

예를 들어, 설정 스크립트를 두 번 호출하여 한 단계에서 모든 것을 빌드한 다음, 두 번째 단계에서 모든 것을 설치할 수 있습니다:

python setup.py build
python setup.py install

이렇게 하면, install 명령을 실행하면 먼저 build 명령이 실행된다는 것을 알 수 있습니다. 이 경우 build 디렉터리의 모든 내용이 최신 상태이므로 수행할 작업이 없음을 빠르게 알 수 있습니다.

‘여러분이 하는 일이 넷에서 다운로드 한 모듈을 설치하는 것뿐이라면, 작업을 분할하는 이 기능이 자주 필요하지 않을 수 있지만, 고급 작업에는 매우 편리합니다. 여러분 자신의 파이썬 모듈과 확장을 배포한다면, 많은 개별 Distutils 명령을 실행하게 됩니다.

빌드 작동 원리

위에서 암시했듯이, build 명령은 설치할 파일을 빌드 디렉터리에 넣는 역할을 합니다. 기본적으로, 이것은 배포 루트 아래의 build입니다; 속도에 지나치게 신경을 쓰거나 소스 트리를 원래 상태로 유지하려면, --build-base 옵션을 사용하여 빌드 디렉터리를 변경할 수 있습니다. 예를 들면:

python setup.py build --build-base=/path/to/pybuild/foo-1.0

(또는 시스템이나 개인 Distutils 구성 파일의 지시문을 사용하여 영구적으로 이렇게 만들 수 있습니다; 섹션 Distutils 구성 파일을 참조하십시오.) 일반적으로, 이 작업은 필요하지 않습니다.

빌드 트리의 기본 레이아웃은 다음과 같습니다:

--- build/ --- lib/
or
--- build/ --- lib.<plat>/
               temp.<plat>/

여기서 <plat>은 현재 OS/하드웨어 플랫폼과 파이썬 버전에 대한 간략한 설명으로 확장됩니다. lib 디렉터리 만 있는 첫 번째 형식은 “순수 모듈 배포”(즉 순수한 파이썬 모듈만 포함하는 모듈 배포)에 사용됩니다. 모듈 배포가 확장(C/C++로 작성된 모듈)을 포함하면, 두 개의 <plat> 디렉터리가 있는 두 번째 형식이 사용됩니다. 이 경우, temp.plat 디렉터리는 실제로 설치되지 않는 컴파일/링크 프로세스에 의해 생성된 임시 파일을 보유합니다. 두 경우 모두, lib (또는 lib.plat) 디렉터리에는 설치될 모든 파이썬 모듈(순수 파이썬과 확장)이 포함됩니다.

향후에는, 파이썬 스크립트, 설명서, 바이너리 실행 파일 및 파이썬 모듈과 응용 프로그램 설치 작업을 처리하는 데 필요한 모든 것을 처리하기 위해 더 많은 디렉터리가 추가될 것입니다.

설치 작동 원리

build 명령이 실행된 후 (명시적으로 실행하든, install 명령이 자동으로 수행하든), install 명령의 작업은 비교적 간단합니다; build/lib (또는 build/lib.plat) 아래의 모든 것을 선택한 설치 디렉터리에 복사하기만 하면 됩니다.

If you don’t choose an installation directory—i.e., if you just run setup.py install—then the install command installs to the standard location for third-party Python modules. This location varies by platform and by how you built/installed Python itself. On Unix (and macOS, which is also Unix-based), it also depends on whether the module distribution being installed is pure Python or contains extensions (“non-pure”):

플랫폼	표준 설치 위치	기본값	노트
유닉스 (순수)	prefix/lib/pythonX.Y/site-packages	/usr/local/lib/pythonX.Y/site-packages	(1)
유닉스 (비순수)	exec-prefix/lib/pythonX.Y/site-packages	/usr/local/lib/pythonX.Y/site-packages	(1)
윈도우	prefix\Lib\site-packages	C:\PythonXY\Lib\site-packages	(2)

노트:

1. 대부분의 리눅스 배포에는 파이썬이 시스템의 표준 부분으로 포함되어 있어서, prefix와 exec-prefix는 일반적으로 리눅스에서 모두 /usr입니다. 리눅스(또는 모든 유닉스 계열 시스템)에서 파이썬을 직접 빌드하면, 기본 prefix와 exec-prefix는 /usr/local입니다.

2. 윈도우의 기본 설치 디렉터리는 파이썬 1.6a1, 1.5.2 및 이전 버전에서 C:\Program Files\Python이었습니다.

prefix and exec-prefix stand for the directories that Python is installed to, and where it finds its libraries at run-time. They are always the same under Windows, and very often the same under Unix and macOS. You can find out what your Python installation uses for prefix and exec-prefix by running Python in interactive mode and typing a few simple commands. Under Unix, just type python at the shell prompt. Under Windows, choose Start ‣ Programs ‣ Python X.Y ‣ Python (command line). Once the interpreter is started, you type Python code at the prompt. For example, on my Linux system, I type the three Python statements shown below, and get the output as shown, to find out my prefix and exec-prefix:

Python 2.4 (#26, Aug  7 2004, 17:19:02)
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.prefix
'/usr'
>>> sys.exec_prefix
'/usr'

이 설명서에는 몇 가지 다른 자리 표시자가 사용됩니다: X.Y는 파이썬 버전을 나타냅니다, 예를 들어 3.2; abiflags는 sys.abiflags 값이나 ABI 플래그를 정의하지 않는 플랫폼에서는 빈 문자열로 대체됩니다; distname은 설치 중인 모듈 배포의 이름으로 대체됩니다. 경로에서 점과 대문자는 중요합니다; 예를 들어, 유닉스에서 python3.2를 사용하는 값은 일반적으로 윈도우에서 Python32를 사용합니다.

표준 위치에 모듈을 설치하고 싶지 않거나, 거기에 쓸 권한이 없다면, 대안 설치 섹션에서 대안 설치에 대해 읽어야 합니다. 설치 디렉터리를 더 많이 사용자 정의하려면, 사용자 정의 설치에 대한 섹션 사용자 정의 설치를 참조하십시오.

대안 설치

종종, 제삼자 파이썬 모듈의 표준 위치가 아닌 다른 위치에 모듈을 설치하는 것이 필요하거나 바람직합니다. 예를 들어, 유닉스 시스템에서 표준 제삼자 모듈 디렉터리에 대해 쓰기 권한이 없을 수 있습니다. 또는 로컬 파이썬 설치의 표준 부분으로 만들기 전에 모듈을 시험해 보고 싶을 수도 있습니다. 이미 존재하는 배포판을 업그레이드할 때 특히 그렇습니다; 실제로 업그레이드하기 전에 기존 스크립트 기반이 새 버전에서 계속 작동하는지 확인하려고 합니다.

Distutils install 명령은 모듈 배포를 대안 위치에 간단하고 쉽게 설치할 수 있도록 설계되었습니다. 기본 아이디어는 여러분이 설치를 위한 기본 디렉터리를 제공하고, install 명령은 이 기본 디렉터리 아래에서 파일을 설치할 디렉터리 집합(설치 체계(installation scheme)라고 합니다)을 선택하는 것입니다. 세부 정보는 플랫폼에 따라 다르므로, 다음 섹션 중 자신에게 해당하는 항목을 읽으십시오.

다양한 대안 설치 체계는 상호 배타적입니다: --user, --home, --prefix와 --exec-prefix, --install-base 및 --install-platbase를 전달할 수 있지만, 이러한 그룹에서 혼합할 수는 없습니다.

대안 설치: 사용자 체계

이 체계는 전역 site-packages 디렉터리에 대해 쓰기 권한이 없거나, 그곳에 설치를 원하지 않는 사용자에게 가장 편리한 솔루션이 되도록 설계되었습니다. 다음과 같은 간단한 옵션으로 활성화됩니다:

python setup.py install --user

Files will be installed into subdirectories of site.USER_BASE (written as userbase hereafter). This scheme installs pure Python modules and extension modules in the same location (also known as site.USER_SITE). Here are the values for UNIX, including macOS:

파일 유형	설치 디렉터리
모듈	userbase/lib/pythonX.Y/site-packages
스크립트	userbase/bin
데이터	userbase
C 헤더	userbase/include/pythonX.Yabiflags/distname

그리고 다음은 윈도우에서 사용되는 값입니다:

파일 유형	설치 디렉터리
모듈	userbase\PythonXY\site-packages
스크립트	userbase\PythonXY\Scripts
데이터	userbase
C 헤더	userbase\PythonXY\Include{distname}

아래에 설명된 다른 체계에 비해 이 체계를 사용하는 이점은 사용자 site-packages 디렉터리가 항상 sys.path에 포함되어있는 정상적인 조건에 있다는 것입니다 (자세한 내용은 site를 참조하십시오), 이는 setup.py 스크립트를 실행한 후에 설치를 완료하기 위해 수행할 추가 단계가 없다는 뜻입니다.

build_ext 명령에도 userbase/include를 헤더 파일의 컴파일러 검색 경로에 추가하고 userbase/lib를 라이브러리의 컴파일러 검색 경로뿐만 아니라 공유 C 라이브러리의 실행 시간 검색 경로(rpath)에 추가하는 --user 옵션이 있습니다.

대안 설치: 홈 체계

“홈 체계”의 배후에 있는 아이디어는 파이썬 모듈의 개인 보관함을 구축하고 유지하는 것입니다. 이 체계의 이름은 유닉스의 “홈(home)” 디렉터리의 아이디어에서 파생되었는데, 유닉스 사용자가 홈 디렉터리를 /usr/이나 /usr/local/과 유사한 배치로 만드는 것이 드문 일이 아니기 때문입니다. 이 체계는 설치하는 운영 체제와 관계없이 누구나 사용할 수 있습니다.

새 모듈 배포판을 설치하는 것은 다음과 같이 간단합니다

python setup.py install --home=<dir>

여기서 --home 옵션에 원하는 디렉터리를 제공할 수 있습니다. 유닉스에서, 게으른 타이피스트는 물결표(~)만 입력할 수 있습니다; install 명령은 이를 여러분의 홈 디렉터리로 확장합니다:

python setup.py install --home=~

파이썬이 이 체계로 설치된 배포판을 찾도록 하려면, 파이썬의 검색 경로를 수정하거나 sitecustomize (site 참조)를 편집하여 site.addsitedir() 을 호출하거나 sys.path를 편집해야 합니다.

--home 옵션은 설치 기본 디렉터리를 정의합니다. 파일은 다음과 같이 설치 기본 디렉터리 아래의 다음 디렉터리에 설치됩니다:

파일 유형	설치 디렉터리
모듈	home/lib/python
스크립트	home/bin
데이터	home
C 헤더	home/include/python/distname

(윈도우를 사용하면 슬래시를 역 슬래시로 바꾸십시오.)

대안 설치: 유닉스 (접두사 체계)

“접두사 체계(prefix scheme)”는 하나의 파이썬 설치를 사용하여 빌드/설치(즉 설정 스크립트 실행)를 수행하지만, 다른 파이썬 설치(또는 다른 파이썬 설치처럼 보이는 무엇)의 제삼자 모듈 디렉터리로 모듈을 설치할 때 유용합니다. 이것이 다소 비정상적으로 들린다면, 실제로 그렇습니다–사용자와 홈 체계가 앞에 나온 이유입니다. 그러나, 접두사 체계가 유용하다고 알려진 사례가 적어도 두 개 있습니다.

첫째, 많은 리눅스 배포판에서 파이썬을 더 전통적인 /usr/local이 아닌 /usr에 넣는다는 점을 고려하십시오. 이 경우 파이썬은 로컬 애드온이 아닌 “시스템”의 일부이기 때문에, 전적으로 적절합니다. 그러나, 소스에서 파이썬 모듈을 설치하면, /usr/lib/python2.X 가 아닌 /usr/local/lib/python2.X 로 보내기를 원할 것입니다. 이것은 다음처럼 할 수 있습니다

/usr/bin/python setup.py install --prefix=/usr/local

또 다른 가능성은 원격 디렉터리에 쓰는 데 사용되는 이름이 이를 읽는 데 사용되는 이름과 다른 네트워크 파일 시스템입니다: 예를 들어, /usr/local/bin/python으로 액세스한 파이썬 인터프리터는 /usr/local/lib/python2.X 에서 모듈을 검색하지만, 해당 모듈은 가령 /mnt/@server/export/lib/python2.X 에 설치해야 합니다. 이것은 다음처럼 할 수 있습니다

/usr/local/bin/python setup.py install --prefix=/mnt/@server/export

두 경우 모두, --prefix 옵션은 설치 기본 디렉터리를 정의하고, --exec-prefix 옵션은 플랫폼별 파일에 사용되는 플랫폼별 설치 기본 디렉터리를 정의합니다. (현재, 이것은 단지 순수하지 않은 모듈 배포를 뜻하지만, C 라이브러리, 바이너리 실행 파일 등으로 확장 할 수 있습니다.) --exec-prefix가 제공되지 않으면, 기본값은 --prefix입니다. 파일은 다음과 같이 설치됩니다:

파일 유형	설치 디렉터리
파이썬 모듈	prefix/lib/pythonX.Y/site-packages
확장 모듈	exec-prefix/lib/pythonX.Y/site-packages
스크립트	prefix/bin
데이터	prefix
C 헤더	prefix/include/pythonX.Yabiflags/distname

--prefix나 --exec-prefix가 실제로 대안 파이썬 설치를 가리킬 필요는 없습니다; 위에 나열된 디렉터리가 아직 존재하지 않으면, 설치 시 만들어집니다.

덧붙여서, 접두사 체계가 중요한 진짜 이유는 단순히 표준 유닉스 설치가 파이썬 자체에서 sys.prefix와 sys.exec_prefix로 제공되는 --prefix와 --exec-prefix를 사용하는 접두사 체계를 사용하는 것입니다. 따라서, 여러분이 접두사 체계를 사용하지 않으리라 생각할 수 있지만, 다른 옵션 없이 python setup.py install을 실행할 때마다 이를 사용하고 있는 것입니다.

대안 파이썬 설치에 확장을 설치하는 것은 해당 확장이 빌드되는 방식에 영향을 미치지 않음에 유의하십시오: 특히, 설치 스크립트를 실행하는 데 사용되는 파이썬 인터프리터와 함께 설치된 파이썬 헤더 파일(Python.h와 그 동료들)이 확장을 컴파일하는 데 사용됩니다. 이러한 방식으로 설치된 확장 프로그램을 실행하는 데 사용되는 인터프리터가 이를 빌드하는 데 사용된 인터프리터와 호환되는지 확인하는 것은 여러분의 책임입니다. 이를 수행하는 가장 좋은 방법은 두 인터프리터가 같은 파이썬 버전(다른 빌드 또는 같은 빌드의 복사본일 수 있습니다)인지 확인하는 것입니다. (물론, --prefix와 --exec-prefix가 대안 파이썬 설치를 가리키지 않으면, 이는 중요하지 않습니다.)

대안 설치: 윈도우 (접두사 체계)

윈도우에는 사용자의 홈 디렉터리에 대한 개념이 없으며, 윈도우에서 표준 파이썬 설치가 유닉스보다 간단하기 때문에, 전통적으로 --prefix 옵션은 윈도우의 별도 위치에 추가 패키지를 설치하는 데 사용되어 왔습니다.

python setup.py install --prefix="\Temp\Python"

이것은 현재 드라이브의 \Temp\Python 디렉터리에 모듈을 설치합니다.

설치 기본 디렉터리는 --prefix 옵션으로 정의됩니다; --exec-prefix 옵션은 윈도우에서 지원되지 않습니다. 이는 순수 파이썬 모듈과 확장 모듈이 같은 위치에 설치됨을 뜻합니다. 파일은 다음과 같이 설치됩니다:

파일 유형	설치 디렉터리
모듈	prefix\Lib\site-packages
스크립트	prefix\Scripts
데이터	prefix
C 헤더	prefix\Include{distname}

사용자 정의 설치

때에 따라, 섹션 대안 설치에 설명된 대안 설치 체계는 여러분이 원하는 것을 수행하지 않습니다. 모든 것을 같은 기본 디렉터리 아래에 유지하면서 한두 개의 디렉터리만 조정하거나, 설치 체계를 완전히 재정의하고 싶을 수 있습니다. 두 경우 모두, 사용자 정의 설치 체계(custom installation scheme)를 만들고 있는 것입니다.

사용자 정의 설치 체계를 만들려면, 대안 체계 중 하나로 시작하고 다음 옵션을 사용하여 다양한 유형의 파일에 사용되는 일부 설치 디렉터리를 재정의합니다:

파일 유형	재정의 옵션
파이썬 모듈	--install-purelib
확장 모듈	--install-platlib
모든 모듈	--install-lib
스크립트	--install-scripts
데이터	--install-data
C 헤더	--install-headers

이러한 재정의 옵션은 상대적이거나, 절대적이거나 또는 설치 기본 디렉터리 중 하나로 명시적으로 정의될 수 있습니다. (두 개의 설치 기본 디렉터리가 있으며, 일반적으로 같습니다—유닉스 “접두사 체계”를 사용하고 다른 --prefix와 --exec-prefix 옵션을 제공할 때만 다릅니다; --install-lib를 사용하면 --install-purelib와 --install-platlib에 대해 계산되거나 제공된 값을 재정의합니다, 그리고 이는 파이썬과 확장 모듈 사이에 차이를 두지 않는 체계에 권장됩니다.)

예를 들어, 유닉스에서 홈 디렉터리에 모듈 배포를 설치한다고 합시다—하지만 스크립트가 ~/bin이 아닌 ~/scripts로 가기를 원합니다. 예상대로, 이 디렉터리를 --install-scripts 옵션으로 재정의할 수 있습니다; 이 경우, 상대 경로를 제공하는 것이 가장 합리적인데, 설치 기본 디렉터리(이 경우, 홈 디렉터리)에 상대적으로 해석됩니다:

python setup.py install --home=~ --install-scripts=scripts

또 다른 유닉스 예: 파이썬 설치가 /usr/local/python 접두사로 빌드되고 설치되었다고 가정하면, 표준 설치 스크립트는 /usr/local/python/bin으로 갑니다. 대신 /usr/local/bin에 넣고 싶으면, --install-scripts 옵션에 대해 이렇게 절대 디렉터리를 제공합니다:

python setup.py install --install-scripts=/usr/local/bin

(이는 “접두사 체계”를 사용하여 설치를 수행합니다, 여기서 접두사는 파이썬 인터프리터가 설치될 때 사용된 것입니다— 이 경우 /usr/local/python입니다.)

윈도우에서 파이썬을 유지하는 경우, 제삼자 모듈이 prefix 자체가 아닌 prefix의 서브 디렉터리에 위치하기를 원할 수 있습니다. 이것은 거의 스크립트 설치 디렉터리를 사용자 정의하는 것만큼 쉽습니다—여러분은 단지 두 가지 유형의 모듈, 파이썬과 확장 모듈이 있다는 것만 신경 쓰면 되는데, 둘 다 하나의 옵션으로 편리하게 제어할 수 있습니다:

python setup.py install --install-lib=Site

지정된 설치 디렉터리는 prefix에 상대적입니다. 물론, 가령 사이트 디렉터리에 .pth 파일을 넣어서 이 디렉터리가 파이썬의 모듈 검색 경로에 있도록 해야 합니다 (site를 참조하십시오). 파이썬의 검색 경로를 수정하는 방법은 섹션 파이썬의 검색 경로 수정하기를 참조하십시오.

전체 설치 체계를 정의하려면, 모든 설치 디렉터리 옵션을 제공하기만 하면 됩니다. 이를 수행하는 권장 방법은 상대 경로를 제공하는 것입니다; 예를 들어, 홈 디렉터리의 python 아래에 모든 파이썬 모듈 관련 파일을 유지하고, 홈 디렉터리를 사용하는 각 플랫폼에 대해 별도의 디렉터리를 원하면, 다음 설치 체계를 정의할 수 있습니다:

python setup.py install --home=~ \
                        --install-purelib=python/lib \
                        --install-platlib=python/lib.$PLAT \
                        --install-scripts=python/scripts
                        --install-data=python/data

또는, 동등하게,

python setup.py install --home=~/python \
                        --install-purelib=lib \
                        --install-platlib='lib.$PLAT' \
                        --install-scripts=scripts
                        --install-data=data

$PLAT은 환경 변수가 아닙니다—구성 파일을 구문 분석할 때와 마찬가지로 명령 줄 옵션을 구문 분석할 때 Distutils에 의해 확장됩니다.

분명히, 새로운 모듈 배포판을 설치할 때마다 전체 설치 체계를 지정하는 것은 매우 지루할 것입니다. 따라서, 이러한 옵션을 Distutils 구성 파일에 넣을 수 있습니다 (섹션 Distutils 구성 파일을 참조하십시오):

[install]
install-base=$HOME
install-purelib=python/lib
install-platlib=python/lib.$PLAT
install-scripts=python/scripts
install-data=python/data

또는, 동등하게,

[install]
install-base=$HOME/python
install-purelib=lib
install-platlib=lib.$PLAT
install-scripts=scripts
install-data=data

설정 스크립트를 실행할 때 다른 설치 기본 디렉터리를 제공하면 이 두 가지는 동등하지 않음에 유의하십시오. 예를 들어,

python setup.py install --install-base=/tmp

은 첫 번째 경우에는 /tmp/python/lib에, 두 번째 경우에는 /tmp/lib에 순수 모듈을 설치합니다. (두 번째 경우에는, /tmp/python으로 설치 기본 디렉터리를 제공하고 싶을 것입니다.)

아마도 샘플 구성 파일 입력에서 $HOME과 $PLAT을 사용하는 것을 눈치챘을 것입니다. 이들은 환경 변수와 매우 유사한 Distutils 구성 변수입니다. 실제로, 이러한 개념이 있는 플랫폼의 구성 파일에서 환경 변수를 사용할 수 있지만, Distutils는 $PLAT과 같이 사용자 환경에 없을 수 있는 몇 가지 추가 변수를 정의합니다. (그리고 물론, Mac OS 9와 같이 환경 변수가 없는 시스템에서는, Distutils가 제공하는 구성 변수만 사용할 수 있습니다.) 자세한 내용은 섹션 Distutils 구성 파일을 참조하십시오.

참고

가상 환경이 활성화되면, 가상 환경 외부에 프로젝트를 실수로 설치하는 것을 방지하기 위해 모든 distutils 구성 파일에서 설치 경로를 변경하는 모든 옵션이 무시됩니다.

파이썬의 검색 경로 수정하기

파이썬 인터프리터가 import 문을 실행할 때, 검색 경로를 따라 파이썬 코드와 확장 모듈을 모두 검색합니다. 경로의 기본값은 인터프리터가 빌드될 때 파이썬 바이너리에 구성됩니다. sys 모듈을 임포트 해서 sys.path 값을 인쇄하여 경로를 파악할 수 있습니다.

$ python
Python 2.2 (#11, Oct  3 2002, 13:31:27)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/local/lib/python2.3', '/usr/local/lib/python2.3/plat-linux2',
 '/usr/local/lib/python2.3/lib-tk', '/usr/local/lib/python2.3/lib-dynload',
 '/usr/local/lib/python2.3/site-packages']
>>>

sys.path의 빈 문자열은 현재 작업 디렉터리를 나타냅니다.

로컬에 설치된 패키지에 대해 기대되는 규칙은 패키지를 …/site-packages/ 디렉터리에 넣는 것이지만, 파이썬 모듈을 임의의 디렉터리에 설치하고 싶을 수 있습니다. 예를 들어, 사이트에 웹 서버와 관련된 모든 소프트웨어를 /www에 유지하는 규칙이 있을 수 있습니다. 그러면 애드온 파이썬 모듈은 /www/python에 속할 수 있으며, 이를 임포트 하려면, 이 디렉터리를 sys.path에 추가해야 합니다. 디렉터리를 추가하는 방법은 여러 가지가 있습니다.

가장 편리한 방법은 이미 파이썬의 경로에 있는 디렉터리(일반적으로 .../site-packages/ 디렉터리)에 경로 구성 파일을 추가하는 것입니다. 경로 구성 파일의 확장자는 .pth이며, 각 줄에는 sys.path에 추가될 단일 경로가 포함되어야 합니다. (새 경로가 sys.path에 추가되기 때문에, 추가된 디렉터리의 모듈은 표준 모듈을 재정의하지 않습니다. 이는 표준 모듈의 수정된 버전을 설치하는데 이 메커니즘을 사용할 수 없음을 의미합니다.)

경로는 절대나 상대일 수 있으며, 상대인 경우 .pth 파일을 포함하는 디렉터리에 상대적입니다. 자세한 내용은 site 모듈 설명서를 참조하십시오.

약간 덜 편리한 방법은 파이썬의 표준 라이브러리에 있는 site.py 파일을 편집하고, sys.path를 수정하는 것입니다. 이 동작을 억제하기 위해 -S 스위치가 제공되지 않는 한, 파이썬 인터프리터가 실행될 때 site.py를 자동으로 임포트 합니다. 따라서 간단히 site.py를 편집하여 두 줄을 추가할 수 있습니다:

import sys
sys.path.append('/www/python/')

그러나, 같은 주 버전의 파이썬을 다시 설치하면 (아마도 예를 들어 2.2에서 2.2.2로 업그레이드 할 때) site.py가 기본 버전으로 덮어 쓰입니다. 설치하기 전에 수정된 것을 기억하고 사본을 저장해야 합니다.

sys.path를 수정할 수 있는 두 가지 환경 변수가 있습니다. PYTHONHOME은 파이썬 설치 접두사에 대한 대안 값을 설정합니다. 예를 들어, PYTHONHOME 을 /www/python으로 설정하면, 검색 경로가 ['', '/www/python/lib/pythonX.Y/', '/www/python/lib/pythonX.Y/plat-linux2', ...]로 설정됩니다.

PYTHONPATH 변수는 sys.path의 시작 부분에 추가될 경로 목록으로 설정할 수 있습니다. 예를 들어, PYTHONPATH가 /www/python:/opt/py로 설정되면, 검색 경로는 ['/www/python', '/opt/py']로 시작합니다. (sys.path에 추가되려면 디렉터리가 존재해야 함에 유의하십시오; site 모듈은 존재하지 않는 경로를 제거합니다.)

마지막으로, sys.path는 일반적인 파이썬 리스트이므로, 모든 파이썬 응용 프로그램은 항목을 추가하거나 제거하여 수정할 수 있습니다.

Distutils 구성 파일

위에서 언급했듯이, Distutils 구성 파일을 사용하여 모든 Distutils 옵션에 대한 개인이나 사이트 기본 설정을 기록할 수 있습니다. 즉, 모든 명령에 대한 모든 옵션이 2개나 3개의 (플랫폼에 따라 다릅니다) 구성 파일 중 하나에 저장될 수 있으며, 명령 줄이 구문 분석되기 전에 참조됩니다. 이는 구성 파일이 기본값을 재정의하고, 명령 줄이 그 후에 구성 파일을 재정의함을 의미합니다. 또한, 여러 구성 파일이 적용되는 경우, “이전” 파일의 값이 “나중” 파일에 의해 재정의됩니다.

구성 파일의 위치와 이름

The names and locations of the configuration files vary slightly across platforms. On Unix and macOS, the three configuration files (in the order they are processed) are:

파일 유형	위치와 파일명	노트
시스템	prefix/lib/pythonver/distutils/distutils.cfg	(1)
개인	$HOME/.pydistutils.cfg	(2)
로컬	setup.cfg	(3)

그리고 윈도우에서, 구성 파일은 다음과 같습니다:

파일 유형	위치와 파일명	노트
시스템	prefix\Lib\distutils\distutils.cfg	(4)
개인	%HOME%\pydistutils.cfg	(5)
로컬	setup.cfg	(3)

모든 플랫폼에서, “개인” 파일은 –no-user-cfg 옵션을 전달하여 일시적으로 비활성화 할 수 있습니다.

노트:

1. 엄밀히 말하면, 시스템 전체 구성 파일은 Distutils가 설치된 디렉터리에 있습니다; 유닉스의 파이썬 1.6 이상에서는, 표시된 것과 같습니다. 파이썬 1.5.2의 경우, Distutils는 일반적으로 prefix/lib/python1.5/site-packages/distutils에 설치되므로, 시스템 구성 파일은 파이썬 1.5.2 에서는 그곳에 넣어야 합니다.

2. 유닉스에서, HOME 환경 변수가 정의되지 않으면, 사용자의 홈 디렉터리는 표준 pwd 모듈의 getpwuid() 함수로 결정됩니다. 이것은 Distutils에서 사용하는 os.path.expanduser() 함수에 의해 수행됩니다.

3. 즉, 현재 디렉터리에 (일반적으로 설정 스크립트의 위치).

4. (노트 (1)도 참조하십시오.) 파이썬 1.6 이상에서, 파이썬의 기본 “설치 접두사”는 C:\Python이므로, 시스템 구성 파일은 일반적으로 C:\Python\Lib\distutils\distutils.cfg입니다. 파이썬 1.5.2에서, 기본 접두사는 C:\Program Files\Python였고, Distutils는 표준 라이브러리의 일부가 아니었습니다—따라서 시스템 구성 파일은 윈도우의 표준 파이썬 1.5.2 설치에서 C:\Program Files\Python\distutils\distutils.cfg입니다.

5. 윈도우에서, HOME 환경 변수가 정의되지 않으면, USERPROFILE 다음에 HOMEDRIVE와 HOMEPATH가 시도됩니다. 이것은 Distutils에서 사용하는 os.path.expanduser() 함수에 의해 수행됩니다.

구성 파일 문법

Distutils 구성 파일은 모두 같은 문법을 갖습니다. 구성 파일은 섹션으로 그룹화됩니다. Distutils 명령마다 하나의 섹션이 있고, 여기에 더해 모든 명령에 영향을 미치는 전역 옵션에 대한 global 섹션이 있습니다. 각 섹션은 option=value로 지정되는 줄당 하나의 옵션으로 구성됩니다.

예를 들어, 다음은 모든 명령이 기본적으로 조용히 실행되도록 하는 완전한 구성 파일입니다:

[global]
verbose=0

이것이 시스템 구성 파일로 설치되면, 현재 시스템의 모든 사용자에 의한 모든 파이썬 모듈 배포 처리에 영향을 줍니다. 개인 구성 파일로 설치되면 (지원하는 시스템에서), 사용자가 처리하는 모듈 배포에만 영향을 줍니다. 그리고 특정 모듈 배포에 대한 setup.cfg로 사용되면, 해당 배포에만 영향을 줍니다.

다음을 사용하여 기본 “빌드 기본(build base)” 디렉터리를 재정의하고 build* 명령이 항상 모든 파일을 강제로 다시 빌드하도록 할 수 있습니다:

[build]
build-base=blib
force=1

이는 다음과 같은 명령 줄 인자에 해당합니다

python setup.py build --build-base=blib --force

명령 줄에 build 명령을 포함하는 것은 명령이 실행된다는 것을 의미한다는 점만 다릅니다. 구성 파일에 특정 명령을 포함하는 것은 그러한 의미가 없습니다; 명령이 실행된다면, 구성 파일의 옵션이 적용된다는 의미일 뿐입니다. (또는 그것에서 값을 파생하는 다른 명령이 실행되면, 그들은 구성 파일의 값을 사용합니다.)

--help 옵션을 사용해서 모든 명령에 대한 전체 옵션 목록을 찾을 수 있습니다. 예를 들어:

python setup.py build --help

그리고 명령 없이 --help를 사용하여 전역 옵션의 전체 목록을 찾을 수 있습니다:

python setup.py --help

“파이썬 모듈 배포” 매뉴얼의 “레퍼런스” 섹션도 참조하십시오.

확장 빌드하기: 팁과 요령

가능하면, Distutils는 setup.py 스크립트를 실행하는 데 사용되는 파이썬 인터프리터에서 제공하는 구성 정보를 사용하려고 합니다. 예를 들어, 파이썬을 컴파일하는 데 사용된 같은 컴파일러와 링커 플래그가 확장 컴파일에도 사용됩니다. 일반적으로 이것은 잘 작동하지만, 복잡한 상황에서는 부적절 할 수 있습니다. 이 섹션에서는 일반적인 Distutils 동작을 재정의하는 방법에 관해 설명합니다.

컴파일러/링커 플래그 조정하기

C나 C++로 작성된 파이썬 확장을 컴파일하려면 특정 라이브러리를 사용하거나 특별한 종류의 오브젝트 코드를 생성하기 위해 컴파일러와 링커에 대해 사용자 지정 플래그를 지정해야 하는 경우가 있습니다. 확장이 플랫폼에서 테스트 되지 않았거나, 파이썬을 크로스 컴파일하려는 경우 특히 그렇습니다.

가장 일반적일 때, 확장 저자는 확장을 컴파일하는 것이 복잡할 것이라고 예상하고, 편집할 Setup 파일을 제공했을 수 있습니다. 이는 모듈 배포에 많은 개별 확장 모듈이 포함되어 있거나, 이들이 작동하기 위해 종종 정교한 컴파일러 플래그 집합이 필요한 경우에만 수행됩니다.

존재한다면, Setup 파일은 빌드할 확장 목록을 얻기 위해 구문 분석됩니다. Setup의 각 줄은 단일 모듈을 설명합니다. 줄의 구조는 다음과 같습니다:

module ... [sourcefile ...] [cpparg ...] [library ...]

각 필드를 차례로 살펴보겠습니다.

• module은 빌드할 확장 모듈의 이름이며, 유효한 파이썬 식별자여야 합니다. 모듈의 이름을 변경하기 위해 단순히 이것을 변경할 수는 없습니다 (소스 코드에 대한 편집도 필요합니다), 따라서 이것은 그대로 두어야 합니다.

• sourcefile은 최소한 파일 이름으로 판단할 때 소스 코드 파일일 가능성이 있는 모든 것입니다. .c로 끝나는 파일명은 C로, .C, .cc 및 .c++로 끝나는 파일명은 C++로, .m이나 .mm으로 끝나는 파일명은 Objective C로 작성되었다고 간주합니다.

• cpparg는 C 전처리기에 대한 인자이며, -I, -D, -U 또는 -C로 시작하는 모든 것입니다.

• library는 .a로 끝나거나 -l이나 -L로 시작하는 모든 것입니다.

특정 플랫폼에 플랫폼의 특수 라이브러리가 필요하면, Setup 파일을 편집하고 python setup.py build를 실행하여 추가 할 수 있습니다. 예를 들어, 다음 줄로 정의된 모듈이

foo foomodule.c

플랫폼의 수학 라이브러리 libm.a와 연결되어야 하면, 간단히 -lm을 줄에 추가하면 됩니다:

foo foomodule.c -lm

컴파일러나 링커 용인 임의의 스위치는 -Xcompiler arg와 -Xlinker arg 옵션으로 제공될 수 있습니다:

foo foomodule.c -Xcompiler -o32 -Xlinker -shared -lm

-Xcompiler과 -Xlinker 다음 옵션은 적절한 명령 줄에 추가되므로, 위의 예에서 컴파일러로는 -o32 옵션을 전달하고, 링커로는 -shared를 전달합니다. 컴파일러 옵션에 인자가 필요하면, 여러 -Xcompiler 옵션을 제공해야 합니다; 예를 들어, -x c++를 전달하려면 Setup 파일에 -Xcompiler -x -Xcompiler c++가 포함되어야 합니다.

CFLAGS 환경 변수 설정을 통해 컴파일러 플래그를 제공할 수도 있습니다. 설정되면, CFLAGS의 내용이 Setup 파일에 지정된 컴파일러 플래그에 추가됩니다.

윈도우에서 비 Microsoft 컴파일러 사용하기

Borland/CodeGear C++

이 서브 섹션에서는 Borland C++ 컴파일러 버전 5.5로 Distutils를 사용하는 데 필요한 단계를 설명합니다. 먼저 Borland의 오브젝트 파일 형식(OMF)이 파이썬이나 ActiveState 웹 사이트에서 다운로드할 수 있는 파이썬 버전에서 사용하는 형식과 다르다는 것을 알아야 합니다. (파이썬은 오브젝트 파일 형식으로 COFF를 사용하는 Microsoft Visual C++로 빌드되었습니다.) 이러한 이유로 파이썬의 라이브러리 python25.lib를 Borland 형식으로 변환해야 합니다. 다음과 같이 할 수 있습니다:

coff2omf python25.lib python25_bcpp.lib

coff2omf 프로그램은 Borland 컴파일러와 함께 제공됩니다. python25.lib 파일은 파이썬 설치의 Libs 디렉터리에 있습니다. 확장이 다른 라이브러리(zlib, …)를 사용하면, 그것들도 변환해야 합니다.

변환된 파일은 일반 라이브러리와 같은 디렉터리에 있어야 합니다.

Distutils는 변경된 이름으로 이러한 라이브러리를 어떻게 사용할까요? 확장에 라이브러리(예를 들어 foo)가 필요하면 Distutils는 접미사가 _bcpp(예를 들어 foo_bcpp.lib)인 라이브러리를 먼저 찾아서 이 라이브러리를 사용합니다. 이러한 특수 라이브러리를 찾지 못하면 기본 이름(foo.lib)을 사용합니다. 1

Distutils가 Borland C++로 확장을 컴파일하도록 하려면 다음을 입력해야 합니다:

python setup.py build --compiler=bcpp

Borland C++ 컴파일러를 기본값으로 사용하려면, Distutils에 대한 개인이나 시스템 전체 구성 파일에 이를 지정할 수 있습니다 (섹션 Distutils 구성 파일을 참조하십시오).

더 보기

C++Builder Compiler

Borland의 무료 C++ 컴파일러에 대한 정보, 다운로드 페이지에 대한 링크를 포함합니다.

Creating Python Extensions Using Borland’s Free Compiler

Borland의 무료 명령 줄 C++ 컴파일러를 사용하여 파이썬을 빌드하는 방법을 설명하는 문서.

GNU C / Cygwin / MinGW

이 섹션에서는 Cygwin과 MinGW 배포판에 있는 GNU C/C++ 컴파일러로 Distutils를 사용하는 데 필요한 단계를 설명합니다. 2 Cygwin으로 빌드된 파이썬 인터프리터의 경우, 다음 단계 없이 모든 것이 작동해야 합니다.

모든 확장이 MinGW나 Cygwin으로 빌드될 수 있는 것은 아니지만, 많은 것들이 가능합니다. 작동하지 않을 가능성이 가장 높은 확장은 C++를 사용하거나 Microsoft Visual C 확장에 의존하는 확장입니다.

Distutils가 Cygwin으로 확장을 컴파일하도록 하려면 다음을 입력해야 합니다:

python setup.py build --compiler=cygwin

그리고 no-cygwin 모드의 Cygwin 3 또는 MinGW의 경우 다음을 입력합니다:

python setup.py build --compiler=mingw32

이러한 옵션/컴파일러를 기본값으로 사용하려면, Distutils에 대한 개인이나 시스템 전체 구성 파일에 작성하는 것을 고려해야 합니다 (섹션 Distutils 구성 파일을 참조하십시오).

이전 버전의 파이썬과 MinGW

다음 지침은 3.0.0(binutils-2.13.90-20030111-1 사용)보다 낮은 MinGW와 함께 2.4.1보다 낮은 파이썬 버전을 사용하는 경우에만 적용됩니다.

이러한 컴파일러에는 몇 가지 특수 라이브러리가 필요합니다. 라이브러리를 변환할 프로그램이 없기 때문에, 이 작업은 Borland의 C++보다 더 복잡합니다. 먼저 파이썬 DLL이 내보내는 심볼 목록을 만들어야 합니다. (https://sourceforge.net/projects/mingw/files/MinGW/Extension/pexports/ 에서 이 작업에 적합한 프로그램을 찾을 수 있습니다.)

pexports python25.dll >python25.def

설치된 python25.dll의 위치는 설치 옵션과 윈도우 버전 및 언어에 따라 다릅니다. “나만을 위한” 설치에서는, 설치 디렉터리의 루트에 나타납니다. 공유 설치에서는, 시스템 디렉터리에 있습니다.

그런 다음 이러한 정보로 gcc 용 임포트 라이브러리를 만들 수 있습니다.

/cygwin/bin/dlltool --dllname python25.dll --def python25.def --output-lib libpython25.a

결과 라이브러리는 python25.lib와 같은 디렉터리에 있어야 합니다. (파이썬 설치 디렉터리 아래의 libs 디렉터리여야 합니다.)

확장이 다른 라이브러리(zlib, …)를 사용하면, 그것들도 변환해야 할 수 있습니다. 변환된 파일은 일반 라이브러리와 같은 디렉터리에 있어야 합니다.

더 보기

Building Python modules on MS Windows platform with MinGW

MinGW 환경에서 필요한 라이브러리를 빌드하는 방법에 대한 정보.

각주

1

이는 또한 기존의 모든 COFF 라이브러리를 같은 이름의 OMF 라이브러리로 바꿀 수 있음을 의미합니다.

2

자세한 내용은 https://www.sourceware.org/cygwin/ 을 확인하십시오.

3

그러면 POSIX 에뮬레이션을 사용할 수 없지만, cygwin1.dll도 필요하지 않습니다.