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

번역·라이선스 안내

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

초록

이 PEP의 목표는 프로젝트에 이미 있는 환경을 더 쉽게 찾을 수 있게 하는 것입니다. 대부분의 도구가 이미 지원하는 가상 환경의 기본 탐색 위치를 정하고, 워크플로 도구가 그 밖의 환경(가상 환경이든 아니든)을 쉽게 나열할 수 있는 방법을 마련하면, 도구는 프로젝트에 있는 모든 환경을 빠짐없이 찾을 수 있게 됩니다.

Mac 노트북에서 바탕 화면의 바로 가기를 더블 클릭하여 Emacs를 실행한다고 상상해 보십시오(“Mac”과 “Emacs”는 각각 선호하는 OS와 편집기로 바꾸어 생각하셔도 됩니다). 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 파일이 있을 수 있습니다(MAY). 이 파일은 프로젝트에 대해 알려진 모든 환경의 목록 역할을 합니다(.venv는 제외하며, 이것과 .python-envs가 함께 동작하는 방식은 뒤에서 다룹니다). .python-envs는 반드시 UTF-8로 인코딩되어야 합니다(MUST). 파일의 각 줄은 프로젝트에서 사용할 수 있는 환경 하나를 나타내며, 각 줄은 \n 또는 \r\n으로 구분될 수 있습니다. 끝에 \n 또는 \r\n 줄바꿈이 오는 것은 허용되며, 이 줄바꿈은 반드시 무시되어야 합니다(MUST).

.python-envs 파일의 각 줄은 환경을 가리키는 경로일 수 있습니다(MAY). 경로는 상대 경로일 수 있으며(MAY), 상대 경로인 경우에는 반드시 .python-envs 파일이 들어 있는 디렉터리를 기준으로 해야 합니다(MUST). 경로가 가상 환경을 가리키는 경우, 그 경로는 반드시 가상 환경의 디렉터리(즉, pyvenv.cfg 파일이 들어 있는 디렉터리)를 가리켜야 합니다(MUST). 한 줄은 어떤 종류의 환경이든 나타낼 수 있습니다(MAY). .python-envs를 읽는 도구는 어떤 종류의 환경을 지원할지 선택할 수 있으며(MAY), 따라서 이해하지 못하는 줄은 무시할 수 있습니다(MAY)(다만 기본 환경을 지원하지 않는 경우에 대해서는 별도의 제약이 있으며, 이는 뒤에서 다룹니다). 도구가 이해할 수는 있지만 어떤 식으로든 잘못된 환경(예: 심볼릭 링크가 더 이상 해석되지 않는 가상 환경)을 어떻게 처리할지는 도구가 결정합니다. 환경을 어떻게 표현하는지, 또는 .python-envs 파일에 어떤 종류의 환경이 들어가는지에 대해서는 이 밖의 제약이 없습니다(NO). 빈 파일은 환경이 하나도 없음을 나타낼 뿐, 그 밖의 특별한 의미는 없습니다(NO).

파일에는 중복된 줄이 있을 수 있습니다(MAY). 같은 환경을 여러 번 나열하는 것에는 아무런 의미가 없습니다(NOT). 어떤 도구든 언제든지 중복을 제거할 수 있지만(MAY), 중복을 제거하는 동안 어떤 환경이 기본 환경으로 간주되는지는 반드시 유지해야 합니다(MUST).

기본 환경이 필요한 경우, .python-envs 파일에 마지막으로 나열된 환경을 반드시 기본 환경으로 간주해야 합니다(MUST). 도구가 마지막으로 나열된 환경을 지원하지 않는 경우, 그 도구는 반드시 어떤 환경을 사용할지 사용자에게 묻거나 오류를 내고 종료해야 합니다(MUST).

.venv 디렉터리 경로에 있는 가상 환경과 .python-envs 파일이 나란히 함께 존재하는 경우, .venv 경로를 반드시 .python-envs 파일의 마지막 줄로 암묵적으로 간주해야 합니다(MUST). 이는 곧 .venv 가상 환경이 기본 가상 환경으로 간주된다는 뜻이기도 합니다.

.python-envs 파일을 버전 관리 시스템에 커밋하는 것은, 프로젝트를 한 번 설정한 뒤 환경의 위치가 고정된 것으로 간주되는 경우에 할 수 있습니다(MAY). 예를 들어, tox를 사용하는 일부 프로젝트는 설정에 “dev” 환경을 정의해 두며, 이 환경은 결국 .tox/dev에 만들어집니다. 그 가상 환경을 가리키도록 .python-envs 파일을 설정하고 이 파일을 체크인하는 것은 합리적입니다. 컨테이너 안에서만 작업하는 프로젝트도 마찬가지입니다. 이런 프로젝트에서는 환경의 위치가 통제되므로 파일 시스템상에서 고정되어 있습니다. 실제 가상 환경을 버전 관리 시스템에 커밋하지 말라는(NOT) 지침은 이 PEP로 인해 바뀌지 않습니다.

도구는 :.python-envs 파일을 읽거나 쓸 때 경쟁 상태가 생기지 않도록 보장하는 데 도움이 되도록 파일 시스템 잠금 메커니즘을 사용할 수 있습니다(MAY).

도구가 이미 사용 중인 환경을 감지할 수 있고(예: VIRTUAL_ENV 환경 변수가 설정된 경우) 이전에 환경을 선택한 적이 없다면, 도구는 사용자의 선택을 존중하여 기본 환경 대신 활성화된/사용 중인 환경을 사용해야 합니다(SHOULD). 활성화된/사용 중인 환경이 감지되면, 도구는 이전의 환경 선택까지도 무시하고 그 환경을 사용하도록 선택할 수 있습니다(MAY).

근거

.venv를 명시적으로 지원하는 것은 이미 관례로 자리 잡은 것을 규칙으로 명문화하기 위함입니다:

Poetry는 그러한 위치에 있는 가상 환경을 감지하며,
PDM은 이미 그 위치에 가상 환경을 생성합니다
uv는 이미 그곳에 환경을 생성합니다
Hatch는 그곳에 가상 환경을 두도록 지원할 수 있습니다)
VS Code
는 이를 자동으로 선택하면서도 여전히 설정을 변경할 수 있게 합니다
PyCharm
은 이를 사용합니다
GitHub에는 .venv를 무시하는 기본 .gitignore가 있습니다
GitLab에는 .venv를 무시하는 기본 .gitignore가 있습니다
Codeberg에는 .venv를 무시하는 기본 .gitignore가 있습니다

하지만 모든 사람이나 도구가 프로젝트 안에 환경을 두려 하거나 .venv라는 이름을 사용하려 하는 것은 아닙니다. 그런 상황에서는 환경을 어디에서 찾을 수 있는지 다른 도구에 알려 줄 _어떤_ 방법이 필요합니다. 그것이 바로 .python-envs 파일의 목적입니다. 이 파일은 프로젝트의 핵심 요소가 아니므로 숨김 파일로 둡니다(환경 자체도 구현 세부 사항으로 볼 수 있습니다). 파일 이름은 그 자체로 의미를 잘 드러내면서도 같은 이름을 사용하는 다른 도구와 충돌하지 않도록 선택했습니다.

개발 중에 여러 환경을 오가며 전환한다는 의견이 있었기 때문에, 이 PEP에 대한 논의에서 여러 환경을 허용하자는 이야기가 여러 번 나왔습니다. 환경 하나가 아니라 사용 가능한 모든 환경을 나열하면 도구가 사용자에게 선택할 수 있는 환경 목록을 보여 줄 수 있으므로 더 나은 UX를 제공할 수 있습니다. 또한 사용해야 할 단일 환경을 기록하는 파일을 상수처럼 끊임없이 다시 작성하는 일을 피하는 데에도 도움이 됩니다.

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

파일 형식은 쉽게 다룰 수 있도록 단순하게 되어 있습니다. 줄 단위로 구분되는 파일 형식이므로 터미널에서 .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를 복잡하게 만들 가치가 없다는 결정이 내려졌습니다. 도구가 자신이 생성한 환경을 추적하고자 한다면, 그것은 각 도구가 자체적인 방식으로 처리할 일입니다. 계속 남아 있는 고아 환경의 경우, 그 외의 환경은 사용자가 직접 선택해야 하므로 기본 환경에 대해서만 문제가 됩니다.

더 구조화된 형식 사용하기

.python-envs에 JSON과 같은 더 구조화된 데이터 형식을 사용하자는 제안이 있었습니다. 대개는 환경에 대한 세부 정보를 .python-envs에 직접 기록하기 위한 목적이었습니다. 그러나 그러한 정보는 환경 자체에서 수집할 수 있는 중복 데이터이므로, 파일 형식을 더 복잡하게 만들 이유가 되지 않는다고 판단되었습니다. 또한 파일 형식이 단순한 덕분에 파일의 목적을 구체적으로 유지하고 기능이 무분별하게 늘어나는 것을 막을 수 있었습니다.

pyproject.toml에 위치 저장하기

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

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

기본 환경을 .python-envs 파일의 시작이 아니라 끝에 두는 것은 주관적인 선택입니다. 결국 이 결정은 읽기와 쓰기 중 어느 쪽을 우선할 것인가의 문제였습니다. 이 PEP는 후자를 택했습니다. 사람은 .python-envs 파일을 읽기보다 쓸 가능성이 더 높으므로, 이 파일에 쓰는 작업을 쉽게 만드는 것이 더 중요하다고 저자가 생각하기 때문입니다(그 결과로, .python-envs 파일은 도구가 코드로 읽을 가능성이 더 높으므로 읽기를 사람에게 맞춰 최적화할 필요는 없습니다).

또한 수백 개의 위치가 담긴 .python-envs 파일을 읽더라도 눈에 띄는 성능 저하는 전혀 없을 것으로 예상합니다.

2026년 8월 10일
- .python-envs에 있는 상대 경로는 해당 파일이 있는 디렉터리를 기준으로 한다는 점을 명확히 했습니다
- 사용자가 사용할 환경을 이전에 선택하지 않았다면 도구는 활성화된 환경을 존중해야 한다(SHOULD)고 명시하고, 이전의 선택을 완전히 재정의할 수 있도록 허용했습니다
- 여러 환경을 지원하는 근거를 제시했습니다
- 예시를 추가했습니다
- tox 및 virtualenv 지원 현황을 나열했습니다
- DoS 우려를 언급했습니다
2026년 7월 31일
- 리디렉션 파일을 .venv에서 .python-envs로 변경했습니다
- venv에 대해 제안했던 변경 사항을 모두 철회했습니다
2026년 4월 23일
- PyCharm 및 library-skills(라이브러리 스킬) 지원을 추가합니다
- 리디렉션 파일을 첫 번째 줄바꿈까지만 읽도록 합니다
- 여러 개의 가상 환경을 두는 것에 대해서는 아무런 입장도 없음을 명확히 했습니다
- 동기를 설명할 때 코드 편집기 예시를 명시적으로 사용했습니다
- venv.executable()에서 가상 환경 이름을 설정할 수 있도록 했습니다
- 심볼릭 링크를 특별한 방식으로 취급하지 않는다는 점을 명확히 했습니다
- 근거(Rationale)를 명세(Specification) 뒤로 옮기고, 세부 사항을 근거로 옮겨 명세를 간결하게 만들었습니다
- “MAY”, “SHOULD”, “NOT”이 들어간 사항을 완화하여, 도구가 리디렉션 파일을 해석하는 방식 외에는 아무것도 하지 않아도 되도록 했습니다

Copyright

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

Python 개선 제안 한국어 번역

PEP 832 – 가상 환경 탐색

초록

동기

명세

근거

예시

이 PEP에 대한 프로젝트 지원

하위 호환성

보안 영향

교육 방법

참조 구현

기각된 아이디어

`.venv`

`.venv` 이외의 이름 사용하기

`.python-envs`

`.venv` 리디렉션 파일

어떤 도구가 환경을 관리하는지 기록하기

더 구조화된 형식 사용하기

pyproject.toml에 위치 저장하기

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

PEP에서 .python-envs 제외하기

.python-envs에 파일 이름 접미사 지원하기

보류된 아이디어

감사의 글

변경 이력

Copyright