PEP 832 – 가상 환경 검색

Author:

Brett Cannon <brett at python.org>

Discussions-To:

Discourse thread

Status:

Draft

Type:

Standards Track

Created:

19-Jan-2026

Python-Version:

3.15

Post-History:

15-Apr-2026 23-Apr-2026 31-Jul-2026 10-Aug-2026

---

Table of Contents

• 초록
• 동기
• 사양
• 근거
• 예시
• 이 PEP에 대한 프로젝트 지원
• 하위 호환성
• 보안 영향
• 이를 가르치는 방법
• 참조 구현
• 거부된 아이디어
  • .venv
    • .venv 이외의 이름 사용
  • .python-envs
    • .venv 리디렉트 파일
    • 환경을 관리하는 도구 기록
    • 더 구조화된 형식 사용
    • pyproject.toml에 위치 저장
    • 기본 환경으로 .python-envs의 첫 번째 항목 사용하기
    • PEP에서 .python-envs 제외하기
    • 파일 이름 접미사 지원: .python-envs
• 보류된 아이디어
• 감사의 말
• 변경 이력
• Copyright

번역·라이선스 안내

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

초록

이 PEP는 프로젝트의 기존 환경을 더 쉽게 검색할 수 있도록 하는 것을 목표로 합니다. 대부분의 도구가 이미 지원하는 가상 환경 검색용 기본 위치를 제공하고, 워크플로 도구가 그 밖의 모든 환경(가상이든 아니든)을 쉽게 나열할 수 있도록 함으로써, 도구가 프로젝트에 존재하는 모든 환경을 찾을 수 있게 합니다.

동기

Mac 노트북을 사용 중이며 데스크톱 바로 가기를 두 번 클릭하여 Emacs를 실행한다고 생각하십시오(각각 선호하는 운영 체제와 편집기에 맞게 “Mac”과 “Emacs”를 자유롭게 바꾸어도 됩니다). Emacs에서 프로젝트 디렉터리를 엽니다. 그렇다면 Emacs(또는 다른 어떤 도구라도)는 프로젝트의 환경이 어디에 있는지 어떻게 알아야 합니까? 터미널에서 실행한 것이 아니므로 VIRTUAL_ENV 환경 변수를 통해 활성화된 가상 환경을 감지할 방법이 없습니다. 가상 환경을 찾기 위해 모든 하위 디렉터리에서 pyvenv.cfg 파일을 검색할 수도 있지만, 이는 가상 환경이 프로젝트와 함께 로컬에 보관되고 여러 환경 중에서 선택하는 것이 아니라 그중 하나만 존재한다고 가정합니다. 또한 모든 프로젝트가 가상 환경을 사용하는 것은 아니며, conda 환경과 같은 다른 프로젝트 격리 메커니즘을 사용할 수도 있습니다.

현재 사용 중인 환경에 접근하여 자동 완성 같은 기능을 제공해야 하는 코드 편집기와 같은 도구는, 어떤 환경이 어디에 있는지 알릴 표준화된 방법이 없는 상황에서 어떻게 해야 합니까? 현재 편집기와 같은 도구는 지원하기로 선택한 각 도구마다 검색 알고리즘을 하드코딩해야 합니다. 또한 지원하는 규칙을 문서화할 수 있지만, 이는 사용자 또는 환경 관리에 사용하는 도구가 그러한 규칙을 따른다고 가정하며, 규칙이라는 특성상 그 내용이 어디에도 기록되어 있지 않습니다.

그리고 이는 가상의 문제가 아닙니다. 이 PEP의 작성자는 7년 동안 VS Code의 Python 지원 개발 관리자였으며, 프로젝트의 환경을 찾는 과정에서 사용자가 겪는 어려움과 끊임없는 기능 요청을 직접 보았습니다.

이 문제는 코드 편집기에만 국한되지 않습니다. 다른 도구들도 무엇이 설치되어 있는지 알기 위해 프로젝트 환경에 접근해야 합니다. 한 가지 예로 타입 검사기는 사용자의 코드를 타입 검사하기 위해 서드파티 코드에 설치된 패키지에 접근하여 타입 어노테이션을 적절히 수집해야 합니다.

이 PEP의 목표는 환경을 생성/관리하는 도구가 프로젝트 환경의 위치를 다른 도구에 알릴 수 있도록 하는 명세를 제공하는 것입니다. 또한 여러 환경이 있는 프로젝트의 경우, 사용자가 그러한 결정을 내리고 싶지 않을 때 환경을 선택하도록 강요받지 않도록 기본으로 사용할 환경을 지정할 수 있게 하는 것이 이 PEP의 목적입니다(예: 코드 편집기를 처음 실행할 때).

이 PEP는 단일 프로젝트에 여러 환경을 두는 것을 용인하거나 권장하지도 않으며, 환경을 하나만 두는 것과 여러 개를 두는 것 중 어느 쪽이 좋거나 나쁜지에 대해서도 중립적이라는 점에 유의하십시오. 또한 특정 환경 유형을 다른 유형보다 우선적으로 권장하지도 않습니다.

사양

이 PEP는 “프로젝트의 루트”가 무엇을 의미하는지 정의하지 않지만, 프로젝트 코드를 작업하기 위해 코드 편집기에서 열 디렉터리라는 것을 전제로 합니다. 이는 프로젝트의 pyproject.toml이 있는 디렉터리일 수도 있고, 모노레포의 최상위 디렉터리일 수도 있습니다.

프로젝트의 가상 환경은 프로젝트 루트에 있는 .venv라는 이름의 경로일 수 있습니다(즉, 가상 환경의 존재를 감지하는 데 사용할 수 있는 .venv/pyvenv.cfg가 존재합니다). 이 PEP는 .venv가 가상 환경을 포함하는 디렉터리를 가리키는 물리적 경로인지 논리적 경로인지, 또는 사용하기 전에 논리적 경로를 이에 대응하는 물리적 경로로 해석해야 하는지에 대해 어떠한 판단도 내리지 않습니다.

프로젝트의 루트에는 .python-envs 파일이 있을 수 있습니다. 이 파일은 프로젝트에 알려진 모든 환경의 목록으로 사용됩니다(.venv 제외; 해당 파일과 .python-envs 파일이 함께 작동하는 방식은 나중에 다룹니다). UTF-8을 사용하여 .python-envs 파일을 인코딩해야 합니다. 파일의 각 줄은 프로젝트에서 사용할 수 있는 환경을 나타내며 \n 또는 \r\n으로 구분될 수 있습니다. \n 또는 \r\n으로 끝나는 후행 개행은 허용되며 반드시 무시해야 합니다.

관련 .python-envs 파일의 각 줄은 환경 경로일 수 있습니다. 경로는 상대 경로일 수 있으며, 상대 경로인 경우 .python-envs 파일을 포함하는 디렉터리를 기준으로 하는 상대 경로여야 합니다. 경로가 가상 환경을 위한 것인 경우, 해당 경로는 가상 환경의 디렉터리(즉, pyvenv.cfg 파일을 포함하는 디렉터리)를 가리켜야 합니다. 한 줄은 어떤 유형의 환경이든 나타낼 수 있습니다. 관련 .python-envs 파일을 읽는 도구는 지원할 환경 유형을 선택할 수 있으므로 이해하지 못하는 줄은 무시할 수 있습니다(단, 기본 환경을 지원하지 않는 경우에 관한 구체적인 제한이 있으며 이는 뒤에서 다룹니다). 도구가 이해하지만 어떤 식으로든 잘못 구성된 환경(예: 심볼릭 링크가 더 이상 확인되지 않는 가상 환경)의 경우, 그러한 상황을 처리하는 방법은 도구가 결정합니다. 환경이 표현되는 방식이나 .python-envs 파일에 포함되는 환경의 유형에 관해서는 다른 제한이 없습니다. 빈 파일은 환경이 전혀 없음을 나타내는 것 외에 특별한 의미가 없습니다.

파일에 중복된 줄이 있을 수 있습니다. 동일한 환경을 여러 번 나열해도 아무런 의미가 없습니다. 어떤 도구든 어느 시점에서든 중복을 제거할 수 있지만, 중복 제거 중 어떤 환경이 기본 환경으로 간주되는지는 유지해야 합니다.

기본 환경이 필요한 경우 .python-envs 파일에 마지막으로 나열된 환경을 기본 환경으로 간주해야 합니다. 도구가 마지막으로 나열된 환경을 지원하지 않는 경우, 사용할 환경을 사용자에게 묻거나 오류를 발생시켜야 합니다.

관련 .venv 디렉터리 경로의 가상 환경과 .python-envs 파일이 나란히 존재한다면, .venv 경로는 반드시 암묵적으로 .python-envs 파일의 마지막 줄로 간주해야 합니다. 이는 또한 .venv 가상 환경이 기본 가상 환경으로 간주된다는 의미입니다.

관련 .python-envs 파일을 버전 관리에 커밋하는 것은 환경이 설정된 후 해당 환경의 위치가 프로젝트에서 고정된 것으로 간주되는 경우 허용됩니다. 예를 들어 tox_를 사용하는 일부 프로젝트에는 구성에 “dev” 환경이 정의되어 있으며, 그 환경은 결국 .tox/dev에 위치합니다. 해당 가상 환경을 가리키도록 .python-envs 파일을 설정하고 그 파일을 체크인하는 것은 합리적입니다. 환경의 위치가 제어되어 파일 시스템에서 고정적인 컨테이너 내부에서만 작업하는 프로젝트에도 마찬가지로 적용됩니다. 실제 가상 환경을 버전 관리에 커밋하지 말라는 지침은 이 PEP로 인해 변경되지 않습니다.

도구는 :.python-envs 파일을 읽거나 쓸 때 경쟁 조건이 발생하지 않도록 보장하는 데 도움을 주기 위해 파일 시스템 잠금 메커니즘을 사용할 수 있습니다.

도구가 환경이 이미 사용 중임을 감지할 수 있는 경우(예: VIRTUAL_ENV 환경 변수가 설정된 경우), 이전에 환경을 선택한 적이 없다면 도구는 사용자의 선택을 존중하여 기본 환경보다 활성화된/사용 중인 환경을 사용해야 합니다. 환경이 활성화되었거나 사용 중인 것으로 감지되면, 도구는 이전에 환경을 선택한 경우에도 이전 환경 선택을 재정의할 수 있습니다.

근거

관련 .venv 파일을 명시적으로 지원하는 것은 이미 관례인 사항을 성문화하기 위한 것입니다:

• Poetry는 해당 위치에서 가상 환경을 감지합니다,
• PDM은 이미 해당 위치에 가상 환경을 생성합니다
• uv는 이미 그곳에 환경을 생성합니다.
• Hatch는 그곳의 가상 환경을 지원할 수 있습니다)

• VS Code

  구성은 계속 허용하면서 이를 자동으로 선택합니다.

• PyCharm

  이를 사용합니다.

• GitHub에는 .venv를 무시하는 기본 .gitignore가 있습니다.
• GitLab에는 .venv를 무시하는 기본 .gitignore가 있습니다.
• Codeberg에는 .venv를 무시하는 기본 .gitignore가 있습니다.

그러나 모든 사람이나 도구가 프로젝트에 환경을 보관하거나 .venv라는 이름을 사용하려는 것은 아닙니다. 그러한 상황에서는 다른 도구에 환경을 찾을 위치를 알려 줄 _some_ 방법이 필요합니다. 그것이 .python-envs 파일의 목적입니다. 파일 자체는 프로젝트의 중요한 측면이 아니므로 숨겨져 있습니다(환경 자체는 구현 세부 사항으로 볼 수 있습니다). 파일 이름은 자체적으로 의미를 드러내면서도 같은 이름을 사용하는 다른 도구와 충돌하지 않도록 선택되었습니다.

사람들이 개발 중 여러 환경 사이를 전환할 것이라고 말하면서 이 PEP에 대한 논의 중 여러 차례 다중 환경 지원이 제기되었습니다. 하나의 환경 대신 사용 가능한 모든 환경을 나열하면 도구가 사용자에게 선택할 환경 목록을 제공할 수 있으므로 UX가 개선됩니다. 또한 사용해야 할 단일 환경을 기록하는 파일을 계속 다시 작성할 필요를 줄이는 데 도움이 됩니다.

관련 .python-envs 파일은 표현할 수 있는 환경 유형에 관해 의도적으로 특정 유형에 구애받지 않습니다. 이는 예상하지 못한 미래의 환경에도 파일을 사용할 수 있도록 합니다. 또한 파일의 한 줄이 나타낼 수 있는 만큼 표현을 느슨하게 두면 도구가 지원할 수도 있고 지원하지 않을 수도 있는 대체 환경을 허용하는 데 도움이 됩니다(예를 들어 SSH를 통한 연결과 같은 가상 환경의 대체 표현도 포함될 수 있습니다). 다만 도구는 악의적인 입력을 사용하지 않도록 해당 줄이 적절하게 사용될 수 있는지 확인해야 합니다.

파일 형식은 쉽게 조작할 수 있도록 단순합니다. 줄로 구분된 파일 형식을 사용하면 터미널을 통해 .python-envs 파일에 줄을 쉽게 추가할 수 있습니다. 예를 들면 다음과 같습니다:

• echo "<path>" >> .python-envs
• Add-Content .python-envs "<path>"
• python3 -c "import sys; p=sys.argv[1]; open('.python-envs', 'a').write(p)" "<path>"

줄 추가를 최대한 간단하게 만들기 위해 .python-envs 파일에 중복된 줄이 나타나는 것이 허용됩니다. 따라서 추가하기 전에 파일을 확인할 필요가 없습니다. 파일에서 후행 개행이 허용되는 것도 이 때문입니다.

파일 형식은 환경에 이미 포함된 정보를 중복하지 않도록 단순하게 구성되어 있습니다. 예를 들어 환경의 이름을 기록하자는 제안이 있었지만, 가상 환경에는 예를 들어 pyvenv.cfg에 프롬프트가 기록되어 있으므로 환경과 별도로 나열할 필요가 없습니다. 그렇게 하면 해당 정보가 오래된 정보가 될 수 있기 때문입니다.

마지막 줄이 기본 환경인 이유도 이것입니다. 사람들이 단순히 사용 가능한 환경을 기록하는 것이 아니라 사용하려는 환경을 추가할 것으로 예상하기 때문입니다. 이 모든 것은 가장 일반적일 것으로 예상되는 작업을 가장 쉽게 만들기 위한 것입니다.

관련 .venv 파일이 .python-envs 파일에서 마지막 환경, 즉 기본 환경을 나타내도록 한 것은 실용적인 이유 때문입니다. 이 PEP보다 먼저 만들어진 도구는 .venv 위치를 사용할 수 있으므로, 이는 하위 호환성을 고려한 것입니다. 또한 사용자가 .venv를 사용하는 그러한 도구를 사용하고 있다면, 이미 해당 가상 환경을 기본 환경으로 간주하고 있을 가능성이 높습니다.

도구가 활성화된 환경을 존중하도록 제안하는 것은 사용자가 환경에 대한 프로젝트별 기본 위치를 재정의할 방법을 갖도록 하기 위한 것입니다(예를 들어 프로젝트가 상대 경로가 포함된 .python-envs 파일을 커밋했지만, 사용자는 모든 환경을 중앙 위치에 저장하려 하므로 해당 위치가 사용되는 것을 전혀 원하지 않는 경우입니다).

예시

/workspace 디렉터리의 .python-envs 파일에 다음 내용이 있었다고 가정하십시오.:

/absolute/path/to/venv
/a/path/to/conda-env
ssh@example.com:custom-path
relative/path/venv

relative/path/venv 디렉터리는 workspace/relative/path/venv로 해석해야 합니다.

이 PEP에 대한 프로젝트 지원

이 PEP에 관해 여러 도구 유지 관리자와 논의한 결과:

Note

지원 여부를 표현한 링크가 없는 도구는 공개적으로 밝혀도 좋다는 허가와 함께 해당 정보를 비공개로 제공했습니다.

• 지원함
  1. VS Code
  2. tox (Bernat Gabor; PoC)
  3. virtualenv (Bernat Gabor; PoC)

하위 호환성

이 PEP의 가상 환경 위치 측면에서는 하위 호환성 문제가 없습니다. .venv가 이 PEP에 하위 호환성을 위해 특별히 포함되었기 때문입니다.

관련 .python-envs 파일의 경우, 해당 파일 이름이 사용되고 있는 것으로 알려져 있지 않습니다. 가장 큰 하위 호환성 우려는 도구가 해당 파일을 생성하지만 예상대로 사용되지 않는 경우입니다. 그다음 우려는 파일이 버전 관리에서 처음부터 무시되지 않는 경우입니다.

보안 영향

잠재적으로 악의적인 .python-envs 파일의 내용을 검사하지 않고 셸 프로세스(예: subprocess.run(..., shell=True))에 전달하는 것은 심각한 보안 문제가 됩니다.

도구가 .venv를 무조건 덮어쓴다면, 사용자가 우연히 해당 디렉터리를 다른 용도로 사용하고 있었을 경우 서비스 거부 공격이 될 수 있습니다. 그러나 .venv를 가상 환경에 사용하는 관례로 인해 이러한 일은 매우 드물게 발생할 것으로 예상됩니다. 도구가 이 문제를 우려한다면 이미 존재하는 위치에 환경을 만들기 전에 사용자에게 확인을 요청할 수 있습니다.

이를 가르치는 방법

새 사용자에게는 python -m venv .venv가 .venv에 가상 환경을 만들며, 사용자를 대신하여 가상 환경을 만드는 다른 도구도 같은 작업을 수행할 수 있다고 알려 줄 수 있습니다.

숙련된 사용자에게는 도구가 .venv에 가상 환경을 만들 수 있다고 알려야 합니다. 또한 다른 환경의 위치를 기록하는 .python-envs 파일이 있을 수 있으며, 마지막으로 나열된 환경이 기본 환경으로 간주된다고 알려야 합니다. 아울러 같은 디렉터리에 .venv와 .python-envs가 모두 존재하면 .venv가 암묵적으로 .python-envs의 마지막 환경, 따라서 기본 환경이 된다는 점도 알려야 합니다.

참조 구현

이 PEP는 코드 변경을 제안하지 않으므로, 말할 수 있는 참조 구현이 없습니다.

거부된 아이디어

.venv

.venv 이외의 이름 사용

일부 사람들은 앞의 . 때문에 일부 도구에서 기본적으로 .venv가 숨겨지는 것을 좋아하지 않거나, 약어로서 venv를 좋아하지 않습니다. 대안에 대한 명확한 합의가 없는 듯하고, 다른 이름은 의미론을 근본적으로 바꾸지 않으며, 기존 도구는 이미 .venv를 지원하는 듯하고, 이 PEP에서 제안한 .python-envs덕분에 환경에 다른 이름을 계속 사용할 수도 있으므로, 이 PEP의 작성자가 해당 이름을 선호하기 때문에 .venv를 선택했습니다. 대체 이름을 논의하는 것은 bikeshedding으로 간주되었습니다.

.python-envs

.venv 리디렉트 파일

이 PEP의 이전 버전에서는 .venv가 가상 환경이 위치한 곳을 가리키는 리디렉트 파일로 작동하도록 허용했습니다. 이는 몇 가지 이유로 .python-envs에 비해 지나치게 제한적인 것으로 밝혀졌습니다.

• 단일 환경만 지원했습니다.
• 가상 환경만 허용하도록 제한되었습니다.

환경을 관리하는 도구 기록

관련 .python-envs 파일에 어떤 도구가 환경을 제공했는지 기록하자는 제안이 있었습니다. 사용자가 도구를 더 이상 사용하지 않게 되거나 사용자에게 명확하지 않은 구성을 변경한 후에도 여전히 존재하지만 프로젝트에 더 이상 유효하지 않은 고아 환경이 생길 가능성이 있다고 생각했습니다.

하지만 이것은 이 PEP의 범위를 벗어나며, 이를 위해 .python-envs를 복잡하게 만들 가치가 없다는 결정을 내렸습니다. 도구가 자신이 생성한 환경을 추적하고 싶다면, 자체적인 방식으로 처리하는 것은 해당 도구에 달려 있습니다. 계속 존재하는 고아 환경의 경우, 사용자가 다른 환경을 선택해야 하므로 기본 환경에 대해서만 문제가 됩니다.

더 구조화된 형식 사용

JSON과 같은 보다 구조화된 데이터 형식을 .python-envs에 사용하자는 제안이 있었습니다. 일반적으로 이는 환경에 대한 세부 정보를 .python-envs에 직접 기록하기 위한 것이었습니다. 하지만 이는 환경 자체에서 수집할 수 있는 중복 데이터이므로, 파일 형식을 더 복잡하게 만들 이유가 아니라고 판단했습니다. 또한 파일 형식의 단순성은 파일의 목표를 구체적으로 유지하고 기능이 불필요하게 확장되는 것을 막는 데 도움이 되었습니다.

pyproject.toml에 위치 저장

환경의 위치를 pyproject.toml에 저장하자는 제안이 있었지만, 너무 경직되어 있다는 이유로 거부되었습니다. 일반적으로 환경 위치는 프로젝트에 따른 선택이 아니라 개인의 선택이거나 도구에 따른 선택입니다. 따라서 위치를 정적으로 지정하는 것은 PEP에 포함할 만큼 충분히 타당해 보이지 않았으며, 특히 프로젝트가 자체 .python-envs 파일을 포함할 수 있기 때문입니다.

기본 환경으로 .python-envs의 첫 번째 항목 사용하기

기본 환경을 .python-envs 파일의 시작이 아닌 끝에 두는 것은 주관적인 선택입니다. 결정은 읽기와 쓰기 중 어느 쪽을 우선할지에 달려 있었습니다. PEP에서는 후자를 선택했습니다. 작성자는 사람이 .python-envs 파일을 읽기보다 여기에 기록할 가능성이 더 높으므로, 파일에 기록하는 작업을 쉽게 만드는 것이 더 중요하다고 생각하기 때문입니다(이에 따른 결론은 도구가 .python-envs 파일을 코드를 통해 읽을 가능성이 더 높으므로 사람이 읽기 편하도록 최적화할 필요는 없다는 것입니다).

또한 수백 개의 위치가 포함된 .python-envs 파일을 읽더라도 어떤 방식으로든 성능이 눈에 띄게 저하되지는 않을 것으로 예상합니다.

PEP에서 .python-envs 제외하기

일부 사람들은 .python-envs를 PEP에서 제외하거나, 아예 이 PEP를 만들지 말자고 제안했습니다. 그러나 이 PEP에 관한 논의 중에 환경이 어디에 있든 관계없이 여러 환경의 위치를 나열할 방법을 원하는 요구가 충분히 강한 것으로 보여 .python-envs를 포함하기로 했습니다.

파일 이름 접미사 지원: .python-envs

파일 접미사에 따라 서로 다른 여러 .python-envs 유사 파일을 허용하자는 제안이 있었습니다. 이 아이디어는 환경의 이름과 용도를 체계화하기 위한 것이었습니다. 이 아이디어를 확장하여 각 파일에 하나의 환경만 포함하도록 할 수도 있었습니다.

결국에는 그 복잡성이 감수할 만한 가치가 없어 보였습니다. 환경은 자체적으로 이름을 지정하는 방식을 가지므로, 그 내용에 관한 단서를 제공할 것입니다. 또한 어떤 환경을 사용할지 선택하는 사람에게 그러한 레이블이 반드시 필요하지는 않을 것입니다. 마지막으로 파일이 너무 많아져 성가실 수도 있습니다.

보류된 아이디어

이 PEP에 관한 논의 중에 좀 더 과감하게 접근하여 워크플로 도구가 다른 도구와 통신하는 방식을 표준화할 방법을 고안해 보자는 제안이 있었습니다. 이렇게 하면 워크플로 도구가 다른 도구에 환경의 위치를 알려 줄 뿐만 아니라 환경을 만들고, 환경에서 명령을 실행하는 등의 작업도 수행할 수 있습니다. 논의는 vote on communication protocols에 투표하고 continue that discussion그 논의를 계속하는 단계까지 진행되었습니다.

그러나 결국 이러한 도구 간 프로토콜은 막대한 작업이 될 것이므로, 이 PEP가 그러한 프로토콜 없이도 독립적으로 성립할 수 있다고 결정했습니다. 그러나 결국 이 PEP는 막대한 작업이 될 도구 간 프로토콜 없이도 독립적으로 성립할 수 있다고 결정되었습니다. 다만 “workflow service protocol”이라는 이름(약칭 “WSP”)은 적어도 정해졌고 대체로 좋은 반응을 얻었습니다. 여기서 WSP는 여러 구문 분석 문법에서 “whitespace”를 의미하기도 합니다.

감사의 말

이 주제에 관한 이전 논의(https://discuss.python.org/t/22922/)에 참여해 주신 모든 분께 감사드립니다. 이 PEP의 초기 초안에 의견을 보내 주신 Hatch의 Cary Hawkins, Poetry의 Randy Döring, PDM의 Frost Ming, virtualenv 및 tox의 Bernát Gábor, venv의 Vinay Sajip, uv의 Zanie Blue께 감사드립니다.

변경 이력

• 2026년 8월 10일
  • 관련 .python-envs 파일의 상대 경로는 해당 파일이 있는 디렉터리를 기준으로 함을 명확히 합니다
  • 사용자가 이전에 사용할 환경을 선택하지 않았다면 도구가 활성화된 환경을 존중해야 한다고 명시하고, 이전 선택을 완전히 재정의할 수 있도록 하십시오.
  • 여러 환경을 지원하는 근거를 제시하십시오.
  • 예를 제공하십시오.
  • tox 및 virtualenv 지원을 나열하십시오.
  • DoS 우려를 언급하십시오.
• 2026년 7월 31일
  • 관련 .venv 리디렉션 파일 방식에서 .python-envs 방식으로 변경했습니다
  • 관련 venv 모듈에 대해 제안된 모든 변경 사항을 폐기했습니다
• 2026년 4월 23일
  • PyCharm 및 library-skills 지원을 추가합니다
  • 리디렉션 파일을 첫 번째 줄바꿈까지 읽도록 합니다
  • 여러 가상 환경을 사용하는 것에 대한 입장이 없음을 명확히 합니다
  • 동기 부여를 위해 코드 편집기 예제를 명시적으로 사용합니다
  • 가상 환경 이름에 대해 venv.executable()을 구성 가능하도록 합니다
  • 심볼릭 링크를 어떤 특별한 방식으로도 처리하지 않음을 명확히 합니다
  • 근거를 사양 다음으로 이동하고, 세부 사항을 근거로 이동하여 후자를 단순화합니다
  • “MAY”, “SHOULD”, “NOT”와 관련된 사항을 완화하여 도구가 리디렉션 파일을 해석하는 방식 이상으로 어떤 작업도 수행할 필요가 없도록 합니다

Copyright

This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.