PEP 405 – Python 가상 환경

Author:

Carl Meyer <carl at oddbird.net>

BDFL-Delegate:

Alyssa Coghlan

Status:

Final

Type:

Standards Track

Topic:

Packaging

Created:

13-Jun-2011

Python-Version:

3.3

Post-History:

24-Oct-2011, 28-Oct-2011, 06-Mar-2012, 24-May-2012

Resolution:

Python-Dev message

---

Table of Contents

• 초록
• 동기
• 명세
  • 시스템 site-packages(사이트 패키지)로부터의 격리
  • 가상 환경 만들기
  • Sysconfig 설치 스킴과 user-site
  • 복사 대 심볼릭 링크
  • include 파일
  • API
• 하위 호환성
  • sys.prefix의 의미 분리
  • 다른 Python 구현에 미치는 영향
• 참조 구현
• Copyright

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

초록

이 PEP는 고유한 site 디렉터리를 가지며, 선택적으로 시스템 site 디렉터리로부터 격리될 수 있는 경량 “가상 환경”을 위한 메커니즘을 Python에 추가할 것을 제안합니다. 각 가상 환경은 고유한 Python 바이너리를 가지며(따라서 다양한 Python 버전으로 환경을 만들 수 있습니다), site 디렉터리에 설치된 독립적인 Python 패키지 집합을 가질 수 있습니다. 다만 표준 라이브러리는 기반으로 설치된 Python과 공유합니다.

동기

Python 가상 환경의 유용성은 기존 서드파티 가상 환경 도구들, 그중에서도 주로 Ian Bicking의 virtualenv가 얻은 인기로 이미 충분히 입증되었습니다. 가상 환경은 이미 의존성 관리와 격리, 시스템 관리자 권한 없이 Python 패키지를 손쉽게 설치하고 사용하는 일, 여러 Python 버전에 걸친 Python 소프트웨어의 자동화된 테스트 등 다양한 용도로 널리 사용되고 있습니다.

기존 가상 환경 도구는 Python 자체의 동작으로부터 지원을 받지 못한다는 문제를 안고 있습니다. rvirtualenv처럼 Python 바이너리를 가상 환경에 복사하지 않는 도구는 시스템 site 디렉터리로부터 신뢰할 수 있는 격리를 제공할 수 없습니다. Python 바이너리를 복사하는 Virtualenv는 매번 시작할 때마다 섬세한 부트스트래핑 과정을 수행하기 위해 Python의 site 모듈 상당 부분을 복제하고, 계속 바뀌는 표준 라이브러리 모듈 집합을 가상 환경에 수동으로 심볼릭 링크하거나 복사할 수밖에 없습니다. (Python은 sys.prefix를 찾기 전에 심볼릭 링크된 실행 파일을 역참조하므로, Virtualenv는 격리를 제공하기 위해 바이너리를 복사해야 합니다.)

가상 환경을 위해 파이썬에 현재 존재하는 유일한 내장 해결책인 PYTHONHOME 환경 변수는 표준 라이브러리 전체를 모든 환경에 복사하거나 심볼릭 링크할 것을 요구합니다. 표준 라이브러리 전체를 복사하는 것은 가벼운 해결책이 아니며, 심볼릭 링크에 대한 크로스 플랫폼 지원도 여전히 일관되지 않습니다(심볼릭 링크를 지원하는 Windows 플랫폼에서도 이를 만들려면 관리자 권한이 필요한 경우가 많습니다).

Python에 통합되고 기존 서드파티 도구에서 쌓은 수년간의 경험을 바탕으로 한 가상 환경 메커니즘은 유지보수 부담을 줄이고, 신뢰성을 높이며, 모든 Python 사용자가 더 쉽게 이용할 수 있습니다.

명세

Python 바이너리가 실행되면 자신의 prefix를 결정하려고 시도하며(이 값은 sys.prefix에 저장됩니다), 이 prefix는 표준 라이브러리와 기타 주요 파일을 찾는 데 사용되고, site 모듈이 사이트 패키지 디렉터리의 위치를 결정하는 데에도 사용됩니다. 현재 접두사는 (PYTHONHOME이 설정되지 않았다고 가정할 때) 먼저 파일 시스템 트리를 거슬러 올라가며 표준 라이브러리의 존재를 나타내는 표식 파일(os.py)을 찾고, 찾지 못하면 바이너리에 하드코딩된 빌드 시점의 접두사로 대체하는 방식으로 결정됩니다.

이 PEP는 이 탐색 과정에 새로운 첫 단계를 추가할 것을 제안합니다. Python 실행 파일과 같은 디렉터리나 그보다 한 단계 위 디렉터리에서 pyvenv.cfg 파일이 발견되면(실행 파일이 심볼릭 링크인 경우 역참조하지 않습니다), 이 파일에서 key = value 형식의 줄을 찾습니다. home 키가 발견되면 이는 해당 Python 바이너리가 가상 환경에 속한다는 뜻이며, home 키의 값은 이 가상 환경을 만드는 데 사용된 Python 실행 파일이 들어 있는 디렉터리입니다.

이 경우 접두사 탐색은 home 키의 값을 실질적인 Python 바이너리 위치로 사용하여 평소와 같이 진행되며, 이를 통해 기반 설치의 접두사를 찾습니다. sys.base_prefix는 이 값으로 설정되고, sys.prefix는 pyvenv.cfg가 들어 있는 디렉터리로 설정됩니다.

(pyvenv.cfg가 발견되지 않거나 home 키를 포함하지 않으면 접두사 탐색은 평소대로 계속되며, sys.prefix는 sys.base_prefix와 같아집니다.)

또한 sys.base_exec_prefix가 추가되며, sys.exec_prefix에 대해서도 같은 방식으로 처리됩니다. (sys.exec_prefix는 sys.prefix에 해당하는 것이지만 플랫폼별 파일을 위한 것이며, 기본적으로 sys.prefix와 같은 값을 가집니다.)

site와 sysconfig 표준 라이브러리 모듈은 표준 라이브러리와 헤더 파일은 sys.base_prefix / sys.base_exec_prefix를 기준으로 찾고, 사이트 패키지 디렉터리(sysconfig 용어로는 “purelib”와 “platlib”)는 여전히 sys.prefix / sys.exec_prefix를 기준으로 찾도록 수정됩니다.

따라서 가장 단순한 형태의 Python 가상 환경은 Python 바이너리의 복사본이나 심볼릭 링크에 pyvenv.cfg 파일과 site-packages(사이트 패키지) 디렉터리가 더해진 것에 불과합니다.

시스템 site-packages(사이트 패키지)로부터의 격리

기본적으로 가상 환경은 시스템 수준의 site-packages(사이트 패키지) 디렉터리로부터 완전히 격리됩니다.

pyvenv.cfg 파일에 값이 true인(대소문자 구분 없음) include-system-site-packages 키도 들어 있으면, site 모듈은 가상 환경 사이트 디렉터리 뒤에 시스템 사이트 디렉터리도 sys.path에 추가합니다. 따라서 시스템에 설치된 패키지도 여전히 임포트할 수 있지만, 가상 환경에 설치된 같은 이름의 패키지가 우선합니다.

PEP 370 사용자 수준 site-packages(사이트 패키지)는 venv의 목적상 시스템 site-packages의 일부로 간주됩니다. 즉, 격리된 venv에서는 사용할 수 없지만 include-system-site-packages = true venv에서는 사용할 수 있습니다.

가상 환경 만들기

이 PEP는 또한 가상 환경 생성을 구현하는 새로운 venv 모듈을 표준 라이브러리에 추가할 것을 제안합니다. 이 모듈은 -m 플래그를 사용하여 실행할 수 있습니다:

python3 -m venv /path/to/new/virtual/environment

이를 더 편리하게 사용할 수 있도록 pyvenv 설치 스크립트도 제공됩니다:

pyvenv /path/to/new/virtual/environment

이 명령을 실행하면 대상 디렉터리가 생성되고(아직 존재하지 않는 상위 디렉터리도 함께 생성됩니다), 그 안에 pyvenv.cfg 파일이 놓입니다. 이 파일에는 명령을 실행한 Python 설치를 가리키는 home 키가 들어 있습니다. 또한 bin/ (Windows에서는 Scripts) 하위 디렉터리도 생성합니다. 이 디렉터리에는 python3 실행 파일의 복사본(또는 심볼릭 링크)과 packaging 표준 라이브러리 모듈의 pysetup3 스크립트가 들어 있습니다(PyPI의 패키지를 새 venv에 쉽게 설치할 수 있도록 하기 위한 것입니다). 그리고 (처음에는 비어 있는) lib/pythonX.Y/site-packages (Windows에서는 Lib\site-packages) 하위 디렉터리를 생성합니다.

대상 디렉터리가 이미 존재하면 오류가 발생합니다. 단, --clear 옵션을 지정한 경우에는 대상 디렉터리를 삭제한 뒤 평소처럼 가상 환경 생성을 진행합니다.

생성된 pyvenv.cfg 파일에는 include-system-site-packages 키도 들어 있습니다. 이 키는 pyvenv를 --system-site-packages 옵션과 함께 실행하면 true로 설정되고, 기본값은 false입니다.

pyvenv에 여러 경로를 지정할 수 있으며, 이 경우 지정한 각 경로에 주어진 옵션에 따라 동일한 venv가 생성됩니다.

venv 모듈은 venv의 bin 또는 Scripts 디렉터리에 POSIX 및 Windows 시스템용 “셸 활성화 스크립트”도 배치합니다. 이 스크립트들은 가상 환경의 bin (또는 Scripts) 디렉터리를 사용자 셸 PATH의 맨 앞에 추가하는 일만 합니다. 가상 환경을 사용하는 데 이 과정이 꼭 필요하지는 않지만(venv의 python 바이너리나 스크립트를 명시적인 경로로 실행해도 똑같이 사용할 수 있으므로), 편리합니다.

pysetup 및 기타 Python 패키지 관리자가 일반 Python 설치와 같은 방식으로 가상 환경에 패키지를 설치할 수 있게 하기 위해, 가상 환경의 내부 구조는 각 플랫폼에서 Python 설치 자체의 구조를 그대로 따릅니다. 이렇게 하면 sysconfig에서도 필요한 곳에 sys.prefix 대신 sys.base_prefix를 사용하는 것 외에는 가상 환경을 특별하게 처리할 필요가 없습니다. 따라서 POSIX 시스템에서 일반적인 가상 환경 구조는 다음과 같습니다:

pyvenv.cfg
bin/python3
bin/python
bin/pysetup3
include/
lib/python3.3/site-packages/

Windows 시스템에서는 다음과 같습니다:

pyvenv.cfg
Scripts/python.exe
Scripts/python3.dll
Scripts/pysetup3.exe
Scripts/pysetup3-script.py
        ... other DLLs and pyds...
Include/
Lib/site-packages/

가상 환경에 설치한 서드파티 패키지의 Python 모듈은 site-packages 디렉터리에, 실행 파일은 bin/ 또는 Scripts에 배치됩니다.

Note

일반적인 Windows 시스템 수준 설치에서는 기본 venv 구조와 달리 Python 바이너리 자체가 “Scripts/” 하위 디렉터리 안에 들어가지 않습니다. 가상 환경에서는 이런 구조가 유용합니다. 사용자가 셸 PATH에 디렉터리 하나만 추가하면 가상 환경이 사실상 “활성화”되기 때문입니다.

Note

Windows에서는 컴파일된 표준 라이브러리 모듈의 DLL 및 pyd 파일도 env에 복사하거나 심볼릭 링크해야 합니다. venv가 시스템 전역이 아닌 Python 설치로부터 생성된 경우, venv에서 Python을 실행하면 Windows가 Python 설치에 있는 해당 파일들을 찾지 못하기 때문입니다.

Sysconfig 설치 스킴과 user-site

이 방식은 의도적으로 venv를 위한 새로운 sysconfig 설치 스킴을 도입하지 않습니다. 대신 sys.prefix를 수정하여, sys.prefix를 기준으로 위치를 정하는 기존 설치 스킴이 venv에서도 그대로 동작하도록 합니다. 경로가 sys.prefix에 상대적이지 않은 다른 설치 스킴(예를 들어 user-site 스킴)을 사용하는 설치는 venv의 영향을 전혀 받지 않습니다.

가상 환경 전용 sysconfig 스킴을 기반으로 Python 가상 환경을 다른 방식으로 구현할 수도 있겠지만, 그렇게 하면 견고성이 떨어집니다. 자신이 가상 환경 안에서 동작하는지 알아야 하는 코드가 더 많아지기 때문입니다.

복사 대 심볼릭 링크

이 PEP의 기법은 일반적으로 Python 바이너리(및 Windows에서 필요한 기타 DLL)를 복사한 경우와 심볼릭 링크한 경우 모두에서 똑같이 잘 동작합니다. 가능한 경우에는 심볼릭 링크를 사용하는 것이 바람직합니다. 기반이 되는 Python 설치를 업그레이드하면 venv에 복사된 Python 실행 파일이 설치된 표준 라이브러리와 맞지 않게 되어 수동으로 업그레이드해야 할 수 있기 때문입니다.

심볼릭 링크에는 플랫폼에 따라 몇 가지 어려움이 있습니다:

• 모든 Windows 버전이 심볼릭 링크를 지원하지는 않으며, 지원하는 버전에서도 심볼릭 링크를 만들려면 관리자 권한이 필요한 경우가 많습니다.
• OS X의 Python 프레임워크 빌드에서 sys.executable은 실제 Python 바이너리를 실행하는 스텁일 뿐입니다. 이 스텁은 심볼릭 링크하면 동작하지 않으므로 반드시 복사해야 합니다. (다행히 스텁은 크기가 작고 Python의 버그 수정 업그레이드로 바뀌지도 않으므로, 복사해도 문제가 되지 않습니다).

따라서 이 PEP는 Windows와 OS X 프레임워크 빌드를 제외한 모든 플랫폼에서 바이너리를 심볼릭 링크하도록 제안합니다. 심볼릭 링크를 지원하는 Windows 버전에서 적절한 권한이 있으면 --symlink 옵션으로 심볼릭 링크를 강제로 사용할 수 있습니다. (OS X 프레임워크 빌드에서는 심볼릭 링크가 절대 동작하지 않고 이점도 없으므로, 이 옵션은 아무 효과가 없습니다).

Windows에서 --symlink를 사용하지 않으면, 기반 Python 설치가 업그레이드될 때 venv 안의 Python 바이너리와 DLL도 업데이트해야 합니다. 그렇지 않으면 업그레이드된 표준 라이브러리와 맞지 않는 문제가 생길 수 있습니다. pyvenv 스크립트는 기존 venv에서 이 업그레이드를 쉽게 수행할 수 있도록 --upgrade 옵션을 받습니다.

include 파일

현재 virtualenv는 include 파일을 다음과 같이 처리합니다:

설치된 Python의 include 파일이 ${base_prefix}/include/pythonX.X에 있는 POSIX 시스템에서는 virtualenv가 ${venv}/include/를 만들고 ${base_prefix}/include/pythonX.X를 ${venv}/include/pythonX.X로 심볼릭 링크합니다. Python의 include 파일이 {{ sys.prefix }}/Include에 있고 심볼릭 링크를 안정적으로 사용할 수 없는 Windows에서는 virtualenv가 {{ sys.prefix }}/Include를 ${venv}/Include로 복사합니다. 이렇게 하면 virtualenv 안에서 빌드되고 설치된 확장 모듈이 필요한 Python 헤더 파일을 항상 sys.prefix를 기준으로 한 예상 위치에서 찾을 수 있습니다.

이 방식은 확장 모듈이 자체 헤더 파일을 설치할 때는 이상적이지 않습니다. 그 헤더 파일의 기본 설치 위치가 쓰기 불가능할 수도 있는 시스템 디렉터리를 가리키는 심볼릭 링크일 수 있기 때문입니다. 설치 프로그램 중 하나인 pip는 헤더 파일을 비표준 위치인 ${venv}/include/site/pythonX.X/에 설치하는 방식으로 이 문제를 명시적으로 우회합니다. 현재 Python에는 site별 include 디렉터리에 대한 표준 추상화가 없기 때문입니다.

이 PEP는 약간 다른 접근 방식을 제안하지만, 본질적으로 효과가 같고 장단점도 같습니다. include 파일을 venv에 심볼릭 링크하거나 복사하는 대신, 헤더 파일을 항상 prefix가 아닌 base_prefix를 기준으로 찾도록 sysconfig 스킴을 수정하기만 합니다. (또한 venv 안에 include/ 디렉터리를 만들어, 설치 프로그램이 env 안에 설치되는 include 파일을 둘 곳을 마련합니다.)

distutils/packaging(패키징)에서, 더 나아가 pyvenv에서 include 파일을 더 잘 처리하는 방안은 향후 별도의 PEP로 다룰 만한 영역일 수 있습니다. 현재로서는 virtualenv의 동작이 지금까지 실제로 적어도 “충분히 괜찮다”는 것을 입증해 왔다고 제안합니다.

API

위에서 설명한 상위 수준 방법은 서드파티 가상 환경 생성 도구가 필요에 따라 환경 생성을 사용자 정의할 수 있는 메커니즘을 제공하는 간단한 API를 사용합니다.

venv 모듈에는 인스턴스를 생성할 때 다음 키워드 인자를 받는 EnvBuilder 클래스가 있습니다:

• system_site_packages - 시스템 Python의 site-packages(사이트 패키지)를 환경에서 사용할 수 있어야 하는지를 나타내는 불리언 값입니다. 기본값은 False입니다.
• clear - 참이면 예외를 발생시키는 대신 기존 대상 디렉터리를 삭제하는 불리언 값입니다. 기본값은 False입니다.
• symlinks - Python 바이너리(및 필요한 DLL이나 기타 바이너리, 예: pythonw.exe)를 복사하는 대신 심볼릭 링크하려고 시도할지를 나타내는 불리언 값입니다. 기본값은 False입니다.

인스턴스화된 env-builder에는 create 메서드가 있으며, 이 메서드는 가상 환경을 담을 대상 디렉터리의 경로(절대 경로 또는 현재 디렉터리 기준 상대 경로)를 필수 인자로 받습니다. create 메서드는 지정된 디렉터리에 환경을 만들거나, 적절한 예외를 발생시킵니다.

venv 모듈은 편의를 위해 모듈 수준의 create 함수도 제공합니다:

def create(env_dir,
           system_site_packages=False, clear=False, use_symlinks=False):
    builder = EnvBuilder(
        system_site_packages=system_site_packages,
        clear=clear,
        use_symlinks=use_symlinks)
    builder.create(env_dir)

서드파티 가상 환경 도구를 만드는 사람은 제공된 EnvBuilder 클래스를 베이스 클래스로 자유롭게 사용할 수 있습니다.

EnvBuilder 클래스의 create 메서드는 사용자 정의에 사용할 수 있는 훅을 보여 줍니다:

def create(self, env_dir):
    """
    Create a virtualized Python environment in a directory.

    :param env_dir: The target directory to create an environment in.

    """
    env_dir = os.path.abspath(env_dir)
    context = self.create_directories(env_dir)
    self.create_configuration(context)
    self.setup_python(context)
    self.post_setup(context)

create_directories, create_configuration, setup_python, post_setup 메서드는 각각 재정의할 수 있습니다. 이 메서드들이 수행하는 함수(역할)는 다음과 같습니다:

• create_directories - 환경 디렉터리와 필요한 모든 디렉터리를 만들고, 컨텍스트 객체를 반환합니다. 이 객체는 다른 메서드가 사용할 속성(경로 등)을 담아 두는 용도일 뿐입니다.
• create_configuration - 환경에 pyvenv.cfg 설정 파일을 생성합니다.
• setup_python - 환경 안에 파이썬 실행 파일의 복사본을 만듭니다(Windows에서는 DLL도 함께 복사합니다).
• post_setup - 서드파티 서브클래스에서 재정의하여 가상 환경에 패키지를 미리 설치하거나 스크립트를 설치할 수 있는 훅 메서드입니다(기본적으로는 아무 동작도 하지 않습니다).

또한 EnvBuilder는 서브클래스의 post_setup에서 호출하여 가상 환경에 사용자 정의 스크립트를 설치하는 데 활용할 수 있는 유틸리티 메서드를 제공합니다. install_scripts 메서드는 context 객체(위 참조)와 디렉터리 경로를 인자로 받습니다. 이 디렉터리에는 “common”, “posix”, “nt” 하위 디렉터리가 있어야 하며, 각 하위 디렉터리에는 환경의 bin 디렉터리에 들어갈 스크립트가 들어 있어야 합니다. “common”의 내용과 os.name에 해당하는 디렉터리의 내용은 플레이스홀더를 몇 가지 텍스트로 치환한 뒤 복사됩니다:

• __VENV_DIR__는 환경 디렉터리의 절대 경로로 치환됩니다.
• __VENV_NAME__은 환경 이름(환경 디렉터리 경로의 마지막 부분)으로 치환됩니다.
• __VENV_BIN_NAME__은 bin 디렉터리의 이름(bin 또는 Scripts)으로 치환됩니다.
• __VENV_PYTHON__은 환경 실행 파일의 절대 경로로 치환됩니다.

참조 구현의 DistributeEnvBuilder 서브클래스는 사용자 정의 훅을 실제로 사용하여 가상 환경에 Distribute를 미리 설치하는 방법을 보여 줍니다. DistributeEnvBuilder가 실제로 Python 코어에 추가될 것으로 예상하지는 않지만, 이를 통해 참조 구현을 테스트와 탐색 목적으로 곧바로 더 유용하게 활용할 수 있습니다.

하위 호환성

sys.prefix의 의미 분리

이러한 방식의 가상 환경 도구(가상 환경에 심볼릭 링크로 연결할 필요 없이 베이스 Python의 표준 라이브러리를 그대로 활용하면서 site-packages(사이트 패키지)를 격리하려는 도구)는 무엇이든, 현재 sys.prefix 하나에 함께 묶여 있는 (여러 의미 중) 서로 다른 두 가지 의미를 분리할 것을 제안하는 셈입니다. 바로 “표준 라이브러리는 어디에 있는가?”와 “서드파티 모듈이 설치되어야 할 site-packages(사이트 패키지) 위치는 어디인가?”라는 질문에 대한 답입니다.

이 분리는 앞의 접두사나 뒤의 접두사 가운데 하나를 위한 새로운 sys 속성을 도입하여 처리할 수 있습니다. 어느 쪽을 택하든 sys.prefix가 다른 쪽 의미라고 가정하고 작성된 소프트웨어와 하위 호환성 문제가 생길 수 있습니다. (그런 소프트웨어는 sys.prefix를 직접 사용하기보다 site 모듈과 sysconfig 모듈의 API를 사용하여 이러한 질문의 답을 구하는 것이 바람직하며, 그렇게 한다면 하위 호환성 문제는 없습니다. 하지만 실제로는 sys.prefix를 직접 사용하는 경우가 종종 있습니다.)

sys.prefix에 대한 문서는 이를 “플랫폼 독립적인 Python 파일이 설치되는 site별 디렉터리 접두사를 나타내는 문자열”로 설명하며, 표준 라이브러리와 헤더 파일이 sys.prefix 아래에 있다고 명시적으로 언급합니다. site-packages에 대해서는 언급하지 않습니다.

문서화된 이 정의를 유지하려면 sys.prefix는 기반 시스템 설치 위치(표준 라이브러리와 헤더 파일이 있는 곳)를 계속 가리키게 두고, site-packages의 접두사를 가리키는 새로운 값(sys.site_prefix 같은 것)을 sys에 도입해야 합니다. 이렇게 하면 문서화된 sys.prefix의 의미는 유지되지만, 서드파티 코드가 site-packages(사이트 패키지) 디렉터리를 찾을 때 sys.site_prefix나 적절한 site API 대신 sys.prefix를 사용하면 격리가 깨질 위험이 있습니다.

가장 대표적인 사례는 아마 setuptools와 그 포크인 distribute일 것입니다. 이 둘은 주로 distutils와 sysconfig API를 사용하지만, pth 파일을 유용하게 둘 수 있는 위치를 사전 점검하기 위한 사이트 디렉터리 목록을 만들 때는 sys.prefix를 직접 사용합니다.

그 밖에는, Google Code Search로 검색해 보면 sys.prefix를 사용해 site-packages 경로를 구성하는 패키지와, 예를 들어 코드 실행 추적에서 표준 라이브러리를 제외하는 데 사용하는 패키지가 대략 비슷한 비율로 섞여 있는 것으로 보입니다.

sys.prefix의 문서화된 정의를 수정해야 하지만, 이 PEP는 sys.prefix가 가상 환경(site-packages가 있는 곳)을 가리키도록 하고, 표준 라이브러리와 Python 헤더 파일을 가리키는 sys.base_prefix를 도입하는 방식을 선호합니다. 이렇게 선택한 근거는 다음과 같습니다:

• 가상 환경을 더 강하게 격리하는 쪽을 택하는 편이 바람직합니다.
• Virtualenv는 이미 sys.prefix가 가상 환경을 가리키도록 수정하고 있으며, 실제로 이것이 문제가 된 적은 없습니다.
• setuptools/distribute는 수정할 필요가 없습니다.

다른 Python 구현에 미치는 영향

이 PEP의 변경 사항 대부분은 다른 Python 구현과 공유되는 표준 라이브러리에서 이루어지므로 아무런 문제도 일으키지 않을 것입니다.

다른 Python 구현은 pyvenv.cfg 파일이 있는 경우 이 파일을 찾고 파싱하는 것을 포함하여, 인터프리터 부트스트랩의 새로운 sys.prefix 탐색 동작을 재현해야 합니다.

참조 구현

참조 구현은 a clone of the CPython Mercurial repository에 있습니다. 이를 테스트하려면 빌드한 뒤 bin/pyvenv /path/to/new/venv를 실행하여 가상 환경을 만드십시오.

Copyright

This document has been placed in the public domain.